<text><span class="style10">Γêå Statement</span><span class="style1">Protect user interface design from any changes that might impair functions supporting data entry, data display, sequence control, user guidance, data transmission, and data protection. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A trade-off is required between design flexibility, to permit needed improvements to the user interface, and design control, to protect current functions from undesirable changes. Some form of continuing configuration management should be instituted to evaluate changes to user interface design, just as for any other critical system interface. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.9/1 Flexible Design for Data Entry2.8/1 Flexible Design for Data Display3.7/1 Flexible Design for Sequence Control4.6/1 Flexible Design for User Guidance5.6/1 Flexible Design for Data Transmission</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>944 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.5 Design Change</span><span class="style21">6.5/2 Protection from Design Change</span></text>
</content>
<name>6.5/2</name>
<script></script>
</card>
card_247444.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data protection requirements may change, which is often the case, provide some means for a system administrator to make necessary changes to data protection functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Data protection functions that may need to be changed include those represented in these guidelines, namely, changes in protective measures regulating user identification, data access, data entry/change, and data transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>943 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.5 Design Change</span><span class="style21">6.5/1 Flexible Design for Data Protection</span></text>
</content>
<name>6.5/1</name>
<script></script>
</card>
card_247265.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Within the constraints of data security, allow users to generate printed copies of transmitted data, including messages sent and received. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">User requirements for printed data are often unpredictable, and printing restrictions may handicap task performance. Rather than restrict printing, establish appropriate procedures for restricting further distribution of printed messages. </span></text>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/7 Printing Messages</span></text>
</content>
<name>6.4/7</name>
<script></script>
</card>
card_246909.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must confirm the identity of a message source, provide computer aids for that purpose. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In military message systems, received commands might be authenticated automatically by requesting computer-generated confirmation codes. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 §ice 1981</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/6 Sender Identification</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>941 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/6 Authenticating Message Sources</span></text>
</content>
<name>6.4/6</name>
<script></script>
</card>
card_246750.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic queuing of incoming messages as necessary to ensure that they will not disrupt current user information handling tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In general, incoming data should not replace currently stored data directly, but should be queued for review and disposition by a user. An exception must be made, however, in applications where automatic updating of current situation data is required for operations monitoring, as in air traffic control systems. In such cases data updating is the primary purpose of the system, and that updating should not require continuous actions by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.5/5 Nondisruptive Notification of Arriving Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>940 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/5 Nondisruptive Notification of Messages Received</span></text>
</content>
<name>6.4/5</name>
<script></script>
</card>
card_246335.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Save a copy of any transmitted message automatically until correct receipt has been confirmed (and possibly longer in some applications). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The primary objective is to prevent irretrievable data loss during transmission. For many system applications, however, the originator of a message will probably want to retain a copy in any case. Any subsequent deletion of that copy should probably be handled as a separate transaction, distinct from data transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>939 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/4 Saving Transmitted Data Until Receipt is Confirmed</span></text>
</content>
<name>6.4/4</name>
<script></script>
</card>
card_246018.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When it is necessary to transmit sensitive data over insecure communication channels, provide automatic encryption to protect such data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not rely on users to remember to request message encryption. A user might be asked to supply an encryption key, but the computer should handle any actual encryption process. </span></text>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/3 Encrypting Messages</span></text>
</content>
<name>6.4/3</name>
<script></script>
</card>
card_245898.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When human judgment may be required to determine whether data are appropriate for transmission, provide users (or a system administrator) some means to review outgoing messages and confirm their release before transmission. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sometimes message release may require coordination among several reviewers in the interests of data protection. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/2 User Review Before Transmission</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>937 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/2 User Review of Data Before Transmission</span></text>
</content>
<name>6.4/2</name>
<script></script>
</card>
card_245695.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that whatever measures are adopted to protect data during transmission -- e.g., encryption, parity checks, buffering until acknowledgment of receipt -- will be applied automatically, without the need for user action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users are fallible, and cannot be relied upon to participate quickly and accurately in the mechanisms of data transmission, whereas that is what computers can do well. The computer should check transmitted data to determine whether an error has occurred; correct errors automatically, if necessary by requesting retransmission; and call to the user's attention any case in which a detected error cannot be automatically corrected. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.4/1 Automatic Protection of Transmitted Data6.0/1 Automated Security Measures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>936 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.4 Data Transmission</span><span class="style21">6.4/1 Automatic Protection of Transmitted Data</span></text>
</content>
<name>6.4/1</name>
<script></script>
</card>
card_245395.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user requests LOG-OFF, check any pending transactions involving data entry/change and, if data loss seems probable, display an appropriate advisory message to the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The user may sometimes suppose that a job is done before taking a necessary further implementing action. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| Current data entries have not been filed; | | save if needed before confirming LOG-OFF. | </span></text>
<text>3.5/11 Preventing Data Loss at LOG-OFF</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>935 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/22 Preventing Data Loss at LOG-OFF</span></text>
</content>
<name>6.3/22</name>
<script></script>
</card>
card_245130.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When simulated data are stored and processed in a system (perhaps for user training), ensure that changes to simulated data are processed separately and do not affect real data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 6.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/30 On-Line Training6.0/6 Segregating Real from Simulated Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>934 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/21 Segregating Real from Simulated Data</span></text>
</content>
<name>6.3/21</name>
<script></script>
</card>
card_244947.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data files may be deleted (or overwritten) by name, ensure that the names of different files are distinctive. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If file names are similar, it is easy for users to make an error in file storage, by specifying an unintended overwriting of one file with data from a similarly named other file. If two or more files are assigned similar names, the distinctive feature should be near the beginning of those names rather than at the end; in particular, no file name should simply be a truncated version of another. In many applications, file naming is a user option, and distinctive naming will depend on user judgment. In such circumstances, users should be offered guidance on good naming procedures. In addition, perhaps the computer might provide an advisory message if a proposed new file name is similar (e.g., identical in the first 5 letters) to the name of an existing file. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>933 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/20 Distinctive File Names</span></text>
</content>
<name>6.3/20</name>
<script></script>
</card>
card_244713.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take explicit action to confirm doubtful and/or potentially destructive data change actions before they are accepted by the computer for execution. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A requirement to take an explicit CONFIRM action will direct user attention to questionable data changes, and help the user avoid the consequences of thoughtless errors. </span></text>
<text>1.3/32 Confirming Actions in DELETE Mode1.3/34 User Confirmation of Editing Changes4.3/18 User Confirmation of Destructive Entries6.0/18 User Confirmation of Destructive Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>932 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/19 User Confirmation of Destructive Actions</span></text>
</content>
<name>6.3/19</name>
<script></script>
</card>
card_244234.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For the entry of related data items, provide automatic cross validation to ensure that the data set is logically consistent. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such cross checking is a significant advantage of on-line data processing, providing computer aids to help users detect logical errors. </span></text>
<text>1.4/1 Combined Entry of Related Data1.7/1 Automatic Data Validation6.3/6 Single Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>931 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/18 Cross Validation of Related Data</span></text>
</content>
<name>6.3/18</name>
<script></script>
</card>
card_244181.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide data validation software which will detect erroneous or doubtful values for data changes, as well as for initial data entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not rely on users always to be correct when entering or changing data. When validity of data entries can be checked automatically, such computer validation will improve the accuracy of data entry. </span></text>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/17 Validating Data Changes</span></text>
</content>
<name>6.3/17</name>
<script></script>
</card>
card_243884.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user requests change (or deletion) of a stored data item that is not currently being displayed, offer to display both the old and new values so that the user can confirm or nullify the change before the transaction is completed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will tend to prevent inadvertent change, including changes resulting in loss of needed data. User attempts at selective data change without displayed feedback will be prone to error. For proposed deletion of significant amounts of data, such as entire files, it will probably not be feasible to display all of the data. In such instances, sufficient information should be provided so that the user can identify those files s/he has selected for deletion. The user should be clearly warned of the potential data loss and required to confirm the destructive action before it will be executed. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/14 Feedback when Changing Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>929 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/16 Displaying Data to be Changed</span></text>
</content>
<name>6.3/16</name>
<script></script>
</card>
card_243508.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display currently operative default values for data entry, so that users can review and confirm them for computer processing. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.1.10</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.8/4 Display of Default Values1.8/5 Easy Confirmation to Enter Default Values</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>928 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/15 Displaying Default Values</span></text>
</content>
<name>6.3/15</name>
<script></script>
</card>
card_243404.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When routine or redundant data can be derived by the computer, display those data automatically for user review, rather than requiring entry by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This represents an exception, in the interests of improved data accuracy, to the general recommendation that data entry/change should occur only as a result of explicit user actions. Automatic data generation by the computer, where it can be based on derived values or cross-file updating, will be faster and more accurate than user entry. In effect, having a computer do automatically what the user may do poorly is here regarded as a form of data protection. </span></text>
<text>1.8/7 Automatic Generation of Routine Data1.8/8 Automatic Computation of Derived Data1.8/10 Automatic Entry of Redundant Data1.8/11 Automatic Cross-File Updating</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>927 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/14 Automatic Data Generation</span></text>
</content>
<name>6.3/14</name>
<script></script>
</card>
card_243074.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When verification of prior data entries is required, allow users to review and confirm the data, rather than requiring re-entry of the data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For routine verification, data review by the user will be quicker than re-entry, with less risk of introducing new errors. For special verification, as when computer processing has detected doubtful and/or discrepant data entries, the user should be alerted with an appropriate advisory message. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/1 Data Entered Only Once1.8/9 User Review of Prior Entries4.3 Error Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>926 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/13 Data Verification by User Review</span></text>
</content>
<name>6.3/13</name>
<script></script>
</card>
card_242777.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to return easily to previous steps in a transaction sequence in order to correct an error or make any other desired change. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The effective implementation of such a BACKUP capability depends upon whether sequences of related transactions can in fact be defined. Any attempt to BACKUP through an arbitrary series of unrelated transactions will pose logical problems both for designers and users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish to BACKUP through the defined sequence of a question-and-answer dialogue in order to change a previous answer. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.7.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/13 Flexible BACKUP for Error Correction</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>925 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/12 Flexible BACKUP for Error Correction</span></text>
</content>
<name>6.3/12</name>
<script></script>
</card>
card_242545.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take an explicit ENTER action for computer processing of error corrections; this should be the same action that was taken to enter the data originally. </span></text>
<text>3.5/6 Explicit Entry of Corrections6.0/9 Control by Explicit User Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>924 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/11 Explicit Entry of Corrections</span></text>
</content>
<name>6.3/11</name>
<script></script>
</card>
card_242182.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Following error detection, allow users to edit entries so that they must rekey only those portions that were in error. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a user must re-enter an entire data set to correct one wrong item, s/he may make new errors in previously correct items. </span></text>
<text>4.3/15 User Editing of Entry Errors6.0/10 User Review and Editing of Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>923 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/10 Editing Entries After Error Detection</span></text>
</content>
<name>6.3/10</name>
<script></script>
</card>
card_242113.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a data entry error is detected by the computer, allow the user to make an immediate correction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Immediate corrections will be made more easily and accurately. Intended entries will still be fresh in the user's mind, and any source data (e.g., documents) will still be available to the user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 5.7MIL-STD-1472C 1983 § 5.15.7.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.7/6 Timely Validation of Sequential Transactions3.5/12 Immediate Data Correction</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>922 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/9 Immediate Error Correction</span></text>
</content>
<name>6.3/9</name>
<script></script>
</card>
card_241904.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to correct keyed data entries (and control entries) before taking an explicit ENTER action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Easy correction before entry will avoid the need for computer processing of user-detected errors. A user should be able to backspace with a nondestructive cursor to the point of error, correct the erroneous item, and ENTER all items without any further cursor positioning. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 5.4Neal Emmons 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/2 Flexible Interrupt3.5/2 Command Editing6.0/10 User Review and Editing of Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>921 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/8 Editing Data Before Entry</span></text>
</content>
<name>6.3/8</name>
<script></script>
</card>
card_241424.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that an ENTER action for multiple data items will result in entry of all items, regardless of where the cursor is placed on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user may choose to move the cursor back in order to correct earlier data items, and cannot be relied upon to move the cursor forward again. The computer should ignore cursor placement in such cases. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/24 Data Entry Independent of Cursor Placement</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>920 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/7 Data Entry Independent of Cursor Placement</span></text>
</content>
<name>6.3/7</name>
<script></script>
</card>
card_241342.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to enter logically related items, as in a form-filling dialogue, with a single, explicit action at the end of the sequence, rather than entering each item separately. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice permits user review and possible data correction prior to entry. It will also permit efficient cross validation of related data items by the computer. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data6.3/18 Cross Validation of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>919 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/6 Single Entry of Related Data</span></text>
</content>
<name>6.3/6</name>
<script></script>
</card>
card_240984.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take some explicit ENTER action to accomplish data entry/change transactions; data change should not occur as a possibly unrecognized side effect of other actions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Explicit actions will help direct user attention to data entry/change, and reduce the likelihood of thoughtless errors. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In some applications it will be desirable to provide automatic cross-file updating of changed data, or generation of routine, redundant or derived data, without requiring explicit action by a user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user should be able to key data into a displayed form but not change stored data unless some explicit ENTER action is taken. A user should be able to point with a lightpen at a displayed item but not change that item unless some further action is taken. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.1.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action1.1/4 Explicit Activation3.0/5 Control by Explicit User Action3.1.3/6 Dual Activation for Pointing4.0/2 Explicit User Actions6.0/9 Control by Explicit User Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>918 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/5 Explicit User Actions</span></text>
</content>
<name>6.3/5</name>
<script></script>
</card>
card_240715.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Make procedures for data entry/change as simple as possible by following guidelines for the design of data entry functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Simple procedures will help ensure accuracy in data entry/change transactions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Allow users to enter short rather than long items, do not require users to enter leading zeros or count blanks, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>917 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/4 Simple Procedures</span></text>
</content>
<name>6.3/4</name>
<script></script>
</card>
card_240568.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In situations where unauthorized data changes may be possible, allow users (or a system administrator) to request a record of data entry/change transactions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Transaction records might be maintained for purposes of user guidance as well as for data protection, as recommended elsewhere. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.4/3 Record of Prior Entries4.4/22 Record of Past Transactions4.5/3 Transaction Records</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>916 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/3 Data Entry/Change Transaction Records</span></text>
</content>
<name>6.3/3</name>
<script></script>
</card>
card_240313.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data must not be changed, maintain computer control over the data, and do not permit users to change controlled items. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is not enough simply to instruct users not to make changes in displayed data. Users may attempt unwanted changes by mistake, or for curiosity, or perhaps even to subvert the system. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.3.12</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/23 Display Format Protection1.4/7 Protected Labels2.0/10 Protection of Displayed Data6.2/3 Protecting Displayed Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>915 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/2 Protection from Data Change</span></text>
</content>
<name>6.3/2</name>
<script></script>
</card>
card_240009.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Establish user authorization for data entry/change at initial LOG-ON; do not require further authorization when a user attempts particular data entry/change transactions. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.1/8 Continuous Recognition of User Identity</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>914 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.3 Data Entry/Change</span><span class="style21">6.3/1 Single Authorization for Data Entry/Change</span></text>
</content>
<name>6.3/1</name>
<script></script>
</card>
card_239747.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that data encryption is reversible, i.e., that encrypted data are protected from any change that might prevent successful reversal of their encryption. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.3/2 Protection from Data Change</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>913 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/10 Ensuring Reversible Encryption</span></text>
</content>
<name>6.2/10</name>
<script></script>
</card>
card_239510.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When sensitive data may be exposed to unauthorized access, provide a capability for encrypting those data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Potential exposure may be assumed during any external data transmission, with encryption imposed routinely by the computer. For protection of data within a shared system, a user might choose to encrypt private files to prevent their reading by other people. In such a case, the user must specify a private encryption "key", which will then serve as the basis for automatic encryption by the computer. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.4/3 Encrypting Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>912 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/9 Encryption</span></text>
</content>
<name>6.2/9</name>
<script></script>
</card>
card_239193.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When records of data access are necessary, the computer should keep those records automatically; do not rely on users to take critical record keeping actions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Even cooperative, well-intentioned users can forget to keep manual logs of data access, and will resent the time and effort required to keep such logs. Subversive users, of course, cannot be expected to provide accurate records. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.5/4 Data Access Records</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>911 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/8 Automatic Records of Data Access</span></text>
</content>
<name>6.2/8</name>
<script></script>
</card>
card_238856.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">As required for security, establish procedures to control access to printed data, rather than simply prohibiting the printing of sensitive data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">User requirements for printed data are often unpredictable, and printing restrictions may handicap task performance. Rather than restrict printing, establish appropriate procedures for restricting further distribution of data printouts. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When confidential information is displayed at a work station that might be viewed by casual onlookers, provide the user with some rapid means of temporarily suppressing a current display if its privacy is threatened, and then resuming work later. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such a capability is sometimes called a "security pause". For quick display suppression a function key might be provided. To retrieve a suppressed display and resume work, a user might be required to make a code entry such as a password, in the interests of data protection. A suppressed display should not be entirely blank, but should contain an appropriate message indicating its current status, e.g., </span><span class="style8">| Display is temporarily suppressed; | | enter password to resume work. | </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/8 PAUSE and CONTINUE Options4.2/1 Consistent Feedback6.1/8 Continuous Recognition of User Identity</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>909 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/6 Display Suppression for Security</span></text>
</content>
<name>6.2/6</name>
<script></script>
</card>
card_238373.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Protect display formatting features, such as field labels and delimiters, from accidental change by users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many data entry tasks users will be allowed to change data fields but should be prevented from making any structural changes to the display. In applications where a user may have to create or modify display formats, special control actions should be provided for that purpose. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When users are not authorized to change displayed data, indicate that "read-only" status on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In applications where the use of read-only displays is common, then some simple cue in the display header may suffice to indicate that status. In applications where users can usually make additions and/or corrections to displayed data, then any exception to that practice may confuse a user and so should be noted more prominently on the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/9 User Changes to Displayed Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>907 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/4 Indicating Read-Only Displays</span></text>
</content>
<name>6.2/4</name>
<script></script>
</card>
card_237934.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When protection of displayed data is essential, maintain computer control over the display and do not permit a user to change such "read-only" data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is not enough simply to instruct users not to make changes in displayed data. Users may attempt unwanted changes by mistake, or for curiosity, or perhaps even to subvert the system. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.4.8MIL-STD-1472C 1983 § 5.15.4.3.12</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/10 Protection of Displayed Data6.3/2 Protection from Data Change</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>906 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/3 Protecting Displayed Data</span></text>
</content>
<name>6.2/3</name>
<script></script>
</card>
card_237790.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When displayed data are classified for security purposes, include a prominent indication of security classification in each display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will serve to remind users of the need to protect classified data, both in access to the display itself and in any further dissemination of displayed data. In applications where either real or simulated data can be displayed, a clear indication of simulated data should be included as part of the classification label. Where a display includes partitioned "windows" of data from different sources, it may be necessary to label security classification separately for each window. Under those conditions, some form of auxiliary coding (e.g., color coding) might help users distinguish a window which contains data at a high security level. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.0/6 Segregating Real from Simulated Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>905 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/2 Displayed Security Classification</span></text>
</content>
<name>6.2/2</name>
<script></script>
</card>
card_237501.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Establish user authorization for data access at initial LOG-ON; do not require further authentication when a user requests display of particular data. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.1/8 Continuous Recognition of User Identity</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>904 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.2 Data Access</span><span class="style21">6.2/1 Single Authorization for Data Access</span></text>
</content>
<name>6.2/1</name>
<script></script>
</card>
card_237243.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Once a user's identity has been authenticated, ensure that whatever data access/change privileges are authorized for that user will continue throughout a work session. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If an identified user is required to take separate actions to authenticate data handling transactions, such as accessing particularly sensitive files or issuing particular commands, the efficiency of system operations may be degraded. Where continuous verification of user identity seems required for data protection, perhaps some automatic means of identification might be devised for that purpose. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In special instances a user's data access/change privileges might reasonably change as a result of succeeding transactions, e.g., if computer analysis indicated suspicious or otherwise abnormal behavior. A user might reasonably be required to repeat procedures for authentication of identity when resuming work after some specified period of inactivity. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Symons Schweitzer 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/10 SUSPEND Option6.2/1 Single Authorization for Data Access6.2/6 Display Suppression for Security6.3/1 Single Authorization for Data Entry/Change</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>903 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/8 Continuous Recognition of User Identity</span></text>
</content>
<name>6.1/8</name>
<script></script>
</card>
card_236917.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When system security requires more stringent user identification than is provided by password entry, devise auxiliary tests that can authenticate user identity without imposing impractical demands on users' memory. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Various means have been proposed for authenticating user identity, including the use of secret algorithms known only to each individual user. If computer-generated cues and user responses can be protected cryptographically from eavesdropping, a practical scheme might be to require a user to respond to a word association test individually devised by that user for this purpose. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Haskett 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>902 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/7 Auxiliary Tests to Authenticate User Identity</span></text>
</content>
<name>6.1/7</name>
<script></script>
</card>
card_236751.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Impose a maximum limit on the number and rate of unsuccessful LOG-ON attempts that will provide a margin for user error while protecting the system from persistent attempts at illegitimate access. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Legitimate users will sometimes have difficulty completing a successful LOG-ON, perhaps due to inattention, or a faulty terminal, or faulty communications. Occasional LOG-ON failures of that kind should be tolerable to the system, with the user simply invited to try again. A record of continuing failure by any particular user to complete successful LOG-ON procedures, including password entry and other tests of claimed user identity, may indicate persistent intrusion attempts. Repeated LOG-ON failures might thus be grounds for denying access to that user. Access might be denied temporarily for some computer-imposed time interval, or indefinitely pending review by a system administrator. The occasional inconvenience to a legitimate user may be tolerable in the interests of increased system security. Analysis of this tradeoff between convenience and security can determine the number and rate of LOG-ON failures that will be tolerated in any particular system application. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>CSC-STD-002-85</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.0/2 Warning of Threats to Security</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>901 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/6 Limiting Unsuccessful LOG-ON Attempts</span></text>
</content>
<name>6.1/6</name>
<script></script>
</card>
card_236335.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a password must be entered by a user, ensure that password entry can be private; password entries should not be displayed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Covert entry of passwords will prevent casual eavesdropping by onlookers. This represents an exception to the general recommendation that all entries should be displayed. In the interests of security, it might be noted that passwords should also not be retained in readable form in computer memory, although this is not an issue of user interface design. </span></text>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/5 Private Entry of Passwords</span></text>
</content>
<name>6.1/5</name>
<script></script>
</card>
card_236168.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to change their passwords whenever they choose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user may sometimes suspect that a password has been disclosed, and thus wish to change it. In addition to optional changes by users, it may also be good security practice for a system to enforce password changes for all users at periodic intervals. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>CSC-STD-002-85</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>899 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/4 Changing Passwords</span></text>
</content>
<name>6.1/4</name>
<script></script>
</card>
card_235942.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When passwords are required, allow users to choose their own passwords. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A password chosen by a user will generally be easier for that individual to remember. User choice is especially helpful when passwords must be periodically changed, with changing demands on memory. In the interests of security, users should be given some guidelines in password selection, so that they will not choose easily guessable nicknames or initials, and will choose passwords of sufficient length to resist random guessing. Some security experts recommend that passwords of nonsense material be composed by a computer and arbitrarily assigned to users, in order to make it more difficult for intruders to guess a password. Such measures will confound legitimate users more often than they will impede intruders, and are not recommended here. A better approach would be to keep passwords memorable, for initial system access, and then impose some auxiliary procedure to authenticate user identity in applications where passwords are considered insufficient protection. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>CSC-STD-002-85Haskett 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>898 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/3 User Choice of Passwords</span></text>
</content>
<name>6.1/3</name>
<script></script>
</card>
card_235553.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the LOG-ON process to provide prompts for all user entries, including passwords and/or whatever other data are required to confirm user identity and to authorize appropriate data access/change privileges. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.11</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>897 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/2 Prompting LOG-ON</span></text>
</content>
<name>6.1/2</name>
<script></script>
</card>
card_235388.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the LOG-ON process and procedures for user identification to be as simple as possible consistent with protecting data from unauthorized use. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some security experts recommend that LOG-ON be made deliberately difficult in order to discourage intruders to a system, and even that the system not indicate the successful completion of a LOG-ON sequence. Such measures will confound legitimate users more often than they will impede intruders, and are not recommended here. A better approach would be to keep the initial LOG-ON simple, and then impose some auxiliary procedure to authenticate user identity. Authentication of user identity is generally not enhanced by requiring a user to enter routine data such as terminal, telephone, office or project numbers. In most organizations, those data can readily be obtained by other people. If verification of those data is needed, the user should be asked to review and confirm currently stored values in a supplementary procedure following LOG-ON. </span></text>
<text>1.8/7 Automatic Generation of Routine Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>896 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.1 User Identification</span><span class="style21">6.1/1 Easy LOG-ON</span></text>
</content>
<name>6.1/1</name>
<script></script>
</card>
card_235158.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to UNDO an immediately preceding control action that may have caused an unintended data loss. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some sort of an UNDO capability is now commonly provided in interface design. UNDO represents one more level of data protection, when warning messages and confirmation procedures fail to prevent error, but can only help the user who notices that an error has been made. In order to implement an UNDO capability, the computer must maintain a record of data changes resulting from current transactions. How long should that record be, i.e., how many transactions should be reversible? Should a user be able to reverse all transactions back to the beginning of a work session? Or all transactions within some defined sequence? Or just the most recent transaction, as recommended here? Whatever UNDO capability is provided, its limitations should be made clear to users. Some designers recommend that UNDO itself should be reversible, so that a second UNDO action will do again whatever was just undone. Such a capability implies that UNDO will affect only the last previous transaction, whatever that was. An alternative would be to offer two different UNDO options, one to reverse mistaken actions and one to reverse mistaken UNDO's, risking considerable user confusion. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to wait for computer prompting in order to CONFIRM a potentially destructive action, so that the confirmation will constitute a second, separate action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">No single user action should cause significant change or loss of stored data, such as deleting an entire data file. Requiring users to strike two keys, such as DELETE followed immediately by CONFIRM, is not sufficient protection; such double keying may become habitual. The DELETE and CONFIRM actions must be separated by some computer response to help ensure user attention. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| Enter next command: D__ | | | | If deleted, all data in this file will be lost. | | Enter YES to confirm deletion: ______ | </span></text>
<text>3.5/7 User Confirmation of Destructive Entries4.3/18 User Confirmation of Destructive Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>894 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/20 Separate CONFIRM Action</span></text>
</content>
<name>6.0/20</name>
<script></script>
</card>
card_234721.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a distinctively labeled CONFIRM function key for user confirmation of potentially destructive actions. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/9 Distinctive CONFIRM Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>893 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/19 Distinctive CONFIRM Action</span></text>
</content>
<name>6.0/19</name>
<script></script>
</card>
card_234449.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take an explicit extra action to CONFIRM a potentially destructive control entry before it is accepted by the computer for execution. </span></text>
<text>1.3/32 Confirming Actions in DELETE Mode1.3/34 User Confirmation of Editing Changes3.1.5/25 Reviewing Destructive Commands3.5/7 User Confirmation of Destructive Entries4.3/18 User Confirmation of Destructive Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>892 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/18 User Confirmation of Destructive Actions</span></text>
</content>
<name>6.0/18</name>
<script></script>
</card>
card_234110.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For conditions which may require special user attention to protect against data loss, provide an explicit alarm and/or warning message to prompt appropriate user action. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/8 User Warned of Potential Data Loss4.3/14 Displaying Erroneous Entries4.3/19 Alarm Coding</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>891 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/17 Warning Users of Potential Data Loss</span></text>
</content>
<name>6.0/17</name>
<script></script>
</card>
card_233907.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the result of user actions will be contingent upon prior selection among differently defined operational modes, provide a continuous indication of the current mode, particularly when user inputs in that mode might result in data loss. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user cannot be relied upon to remember prior actions. Thus any action whose results are contingent upon previous actions can represent a potential threat to data protection. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a DELETE mode is being used to edit displayed data, some indication of that mode should be continuously displayed to the user. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take explicit action to select any operational mode that might result in data loss; the computer should not establish destructive modes automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications, it may be better not to provide any destructive mode. Instead of providing a DELETE mode, for example, require that DELETE be a discrete action subject to confirmation by the user when the requested data deletion is extensive. User interface design must determine the proper balance here between data protection and operational efficiency. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In text editing, if a user takes a DELETE action, that in itself should not establish a continuing DELETE mode. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/32 Confirming Actions in DELETE Mode4.2/8 Indicating Operational Mode</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>889 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/15 Explicit Action to Select Destructive Modes</span></text>
</content>
<name>6.0/15</name>
<script></script>
</card>
card_233253.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that user interface software will deal appropriately with all possible user errors and random inputs, without introducing unwanted data change. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The interface designer must try to anticipate every possible user action, including random keying and perhaps even malicious experimentation. The user interface should be "bullet-proofed" so that an unrecognized entry at any point will produce only an error message and will not change stored data. </span></text>
<text>3.5/1 Appropriate Response to All Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>888 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/14 Safe Response to Random Inputs</span></text>
</content>
<name>6.0/14</name>
<script></script>
</card>
card_233088.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If automatic defaults are provided for control entries, ensure that those defaults will protect against data loss, or at least not contribute to the risk of data loss. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When requesting a printout of filed data, one control option might be to delete that file after printing; the default value for such a destructive option should automatically be set to NO whenever the printing options are presented to a user for selection. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>887 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/13 Safe Defaults</span></text>
</content>
<name>6.0/13</name>
<script></script>
</card>
card_232758.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If activation of function keys (and other control devices) may result in data loss, locate them separately and/or physically protect them to reduce the likelihood of accidental activation. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.1.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.4/18 Layout Compatible with Use</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>886 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/12 Protecting Physical Controls</span></text>
</content>
<name>6.0/12</name>
<script></script>
</card>
card_232559.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When function keys and other devices are not needed for current control entry, and especially when they may have destructive effects, disable them temporarily under software control so that they cannot be activated by a user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some means should also be provided to help users distinguish currently active from disabled controls, such as brightening (active) or dimming (disabled) their associated labels. If labeling is adequate, then user selection of a disabled control need produce no response. If adequate labeling cannot be provided, then user selection of a disabled control should produce an advisory message that the control is not currently active. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.4/12 Disabling Unneeded Function Keys3.2/10 Only Available Options Offered</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>885 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/11 Disabling Unneeded Controls</span></text>
</content>
<name>6.0/11</name>
<script></script>
</card>
card_232282.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For all inputs, whether data entries or commands, allow users to edit composed material before requesting computer processing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Input editing will allow users to correct many errors before computer processing. When an error is detected, a user will be able to fix it by editing, i.e., without having to retype any correct items (which might introduce further errors). </span></text>
<text>1.4/2 Flexible Interrupt3.5/2 Command Editing4.3/15 User Editing of Entry Errors</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>884 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/10 User Review and Editing of Entries</span></text>
</content>
<name>6.0/10</name>
<script></script>
</card>
card_232086.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer changes data only as a result of explicit actions by a user, and does not initiate changes automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The aim here is to preserve clarity of system operation for the user. In effect, a computer should not initiate data changes unless requested (and possibly confirmed) by a user. Well-intentioned interface designers are sometimes tempted to contrive "smart shortcuts" in which one user action might automatically produce several other associated data changes, perhaps saving the user a few keystrokes in special cases. If such shortcuts cannot be made standard procedures, they will tend to confuse users and thus pose a potential threat to data protection. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In an operations monitoring situation, a computer might accept data changes automatically from external sources (sensors), if appropriate software is incorporated to ensure validation and protection of the input data. A computer might perform cross-file updating automatically, following data change by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action1.1/4 Explicit Activation3.0/5 Control by Explicit User Action3.1.3/6 Dual Activation for Pointing3.5/6 Explicit Entry of Corrections4.0/2 Explicit User Actions5.0/6 Control by Explicit User Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>883 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/9 Control by Explicit User Action</span></text>
</content>
<name>6.0/9</name>
<script></script>
</card>
card_231912.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the ease of user actions will match desired ends; make frequent or urgent actions easy to take, but make potentially destructive actions sufficiently difficult that they will require extra user attention. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>882 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/8 Appropriate Ease or Difficulty of User Actions</span></text>
</content>
<name>6.0/8</name>
<script></script>
</card>
card_231194.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide clear and consistent procedures for different types of transactions, particularly those involving data entry, change and deletion, and error correction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent procedures will help users develop consistent habits of operation, reduce the likelihood of user confusion and error, and are especially important for any transaction that risks data loss. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.2.1 2.1.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/1 Standard Procedures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>881 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/7 Consistent Procedures</span></text>
</content>
<name>6.0/7</name>
<script></script>
</card>
card_230951.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When simulated data and system functions are provided (perhaps for user training), ensure that real data are protected and real system use is clearly distinguished from simulated operations. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 6.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/30 On-Line Training6.3/21 Segregating Real from Simulated Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>880 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/6 Segregating Real from Simulated Data</span></text>
</content>
<name>6.0/6</name>
<script></script>
</card>
card_230737.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a proposed user action will interrupt a current transaction sequence, provide automatic means to prevent data loss; if potential data loss cannot be prevented, warn the user and do not interrupt without user confirmation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some interrupt actions such as BACKUP, CANCEL, or REVIEW, will by their definition cause only limited data change, and so need no special protection. However, if an interrupt action may cause extensive data change (e.g., RESTART, LOG-OFF), then require the user to confirm that action before processing. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user should interrupt a series of changes to a data file, then the computer might automatically save both the original and the changed versions of that file for subsequent user review and disposition. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/6 RESTART Option</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>879 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/5 Protection from Interrupts</span></text>
</content>
<name>6.0/5</name>
<script></script>
</card>
card_230578.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Protect data from inadvertent loss caused by the actions of other users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In systems where information handling requires the coordinated action of multiple users, it may be appropriate that one user can change data that will be used by others. But when multiple users will act independently, then care should be taken to ensure that they will not interfere with one another. Extensive system testing under conditions of multiple use may be needed to determine that unwanted interactions do not occur. When one user's actions can be interrupted by another user, as in defined emergency situations, that interruption should be temporary and nondestructive. The interrupted user should subsequently be able to resume operation at the point of interruption without data loss. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.6.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/22 Control by Simultaneous Users</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>878 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/4 Protection from Interference by Other Users</span></text>
</content>
<name>6.0/4</name>
<script></script>
</card>
card_230359.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic measures to minimize data loss from computer failure. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An automatic capability is needed because users cannot be relied upon to remember to take necessary protective measures. Though not strictly a feature of user interface design, reliable data handling by the computer will do much to maintain user confidence in the system. Conversely, data loss resulting from computer failure will weaken user confidence, and reduce user acceptance where system use is optional. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Depending upon the criticality of the application, different protective measures may be justified, including periodic automatic archiving of data files, maintenance of transaction logs for reconstruction of recent data changes, or even provision of parallel "backup" computing facilities. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.6.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>877 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/3 Protection from Computer Failure</span></text>
</content>
<name>6.0/3</name>
<script></script>
</card>
card_229989.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide computer logic that will generate messages and/or alarm signals in order to warn users (and system administrators) of potential threats to data security, i.e., of attempted intrusion by unauthorized users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For protecting data from unauthorized use, it may not be enough merely to resist intrusion. It may also be helpful if the computer can detect and report any intrusion attempts. In the face of persistent intrusion attempts, it may be desirable to institute countermeasures of some sort, such as changing user passwords or establishing other more stringent user authentication procedures. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.1.3CSC-STD-002-85</text>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/2 Warning of Threats to Security</span></text>
</content>
<name>6.0/2</name>
<script></script>
</card>
card_229764.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Whenever possible provide automated measures to protect data security, relying on computer capabilities rather than on more fallible human procedures. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For protection against unauthorized users, who may be intruders in a system, the need for automated security measures is clear. For legitimate users, the need for data protection is to minimize data loss resulting from potentially destructive equipment failures and user errors. Even careful, conscientious users will sometimes make mistakes, and user interface logic should be designed to help mitigate the consequences of those mistakes. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>875 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA PROTECTION</span><span class="style20">6.0 General</span><span class="style21">6.0/1 Automated Security Measures</span></text>
</content>
<name>6.0/1</name>
<script></script>
</card>
card_229530.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data transmission requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to transmission functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Data transmission functions that may need to be changed include those represented in these guidelines, namely, changes in message preparation and addressing, the initiation and control of message transmission, and the handling of received messages. Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/7 Flexible User Control5.1/2 User-Designed Message Formats5.2/1 Destination Selection5.3/4 Computer-Initiated Transmission5.4/3 User Specification of Feedback5.5/1 Specifying Sources</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>874 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.6 Design Change</span><span class="style21">5.6/1 Flexible Design for Data Transmission</span></text>
</content>
<name>5.6/1</name>
<script></script>
</card>
card_229177.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to discard unwanted messages without filing them, or even without reading them in applications where "junk mail" may be received. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Discarding messages, like other user actions, should be reversible. That is to say, a discarded message should be filed temporarily in some "wastebasket" from which it could later be retrieved if the user has not yet left the system. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>873 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/18 Discarding Messages</span></text>
</content>
<name>5.5/18</name>
<script></script>
</card>
card_228943.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify "filters" based on message source, type, or content, that will control how messages should be filed. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might want to file in a single "folder" all messages about a particular topic. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/9 Flexible Message Filing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>872 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/17 Filters for Message Filing</span></text>
</content>
<name>5.5/17</name>
<script></script>
</card>
card_228751.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to append notes to a received message, and ensure that such annotation will be displayed so that it will be distinct from the message itself. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In most applications, users should not be allowed to make changes in received messages. Any such changes would simply provide too much chance for resulting confusion. But users should be able to append, file, and display in some distinctively separate form, their own comments about received messages. If changes are desired in a message itself, then its recipient might make a copy of that message (with appropriate change of its header information) and then edit that copy. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>871 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/16 Annotating Received Messages</span></text>
</content>
<name>5.5/16</name>
<script></script>
</card>
card_228536.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to assign their own names and other descriptors to received messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user might wish to file received messages for future reference. User-assigned labels could help identify a stored message and distinguish it from other filed messages. In the absence of labeling by a recipient, the computer might assign by default whatever descriptors have been provided by the message sender. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>870 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style22"></span><span class="style21">5.5/15 Labeling Received Messages</span></text>
</content>
<name>5.5</name>
<script></script>
</card>
card_228291.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that computer aids and procedures for reviewing messages are consistent with other system capabilities for general data display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users should not have to learn procedures for reviewing messages that are different from general data display, particularly if those procedures might involve conflicting habits. Users should be able to page or scroll through a summary list of messages, or a particular displayed message, just as they might manipulate any other data display. Users should be able to select items from a displayed summary list of messages, just as they might select items from a displayed menu of control options. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/3 Consistent Procedures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>869 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/14 Message Review Compatible with Data Display</span></text>
</content>
<name>5.5/14</name>
<script></script>
</card>
card_227908.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify "filters" based on message source, type, or content, that can control the order in which received messages will be read. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The aim here is to facilitate flexible user control over the review of incoming messages. In particular, a user should not be constrained to read incoming messages in the order in which they are received. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/7 Flexible User Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>868 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/13 Filters for Ordering Message Review</span></text>
</content>
<name>5.5/13</name>
<script></script>
</card>
card_227647.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide convenient means for user review of received messages in their incoming queue, without necessarily requiring any further disposition action, i.e., without removal from the queue. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Rapid review of queued messages will permit a user to exercise judgment as to which require immediate attention, and/or which can be dealt with quickly. Other messages may be left in the queue for more leisurely disposition later. A user with limited facilities for data storage might not be able to accept for immediate filing all of the messages received during a prolonged absence from the system. In such circumstances it seems clear that the user should be able to review received messages before deciding which to store in personal files. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In some operational applications, user review of critical messages might be accompanied by a requirement for further actions to ensure timely response. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>867 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/12 User Review of Messages in Queue</span></text>
</content>
<name>5.5/12</name>
<script></script>
</card>
card_227425.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide some means for users to specify the order in which header fields are displayed in messages and in message summary listings. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users should be able to assign names to various stored header format specifications of this kind, so that a particular desired header format might be invoked by name. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For different purposes, a user might wish to display messages with the topic on the first line, or with the sender's name on the first line. A user might wish to scan a summary list of messages grouped by topic, or by sender, or by priority, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>866 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/11 Specifying Format for Message Listings</span></text>
</content>
<name>5.5/11</name>
<script></script>
</card>
card_227118.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Include in summary listings and at the beginning of each message some indication of message size. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Message size might be calculated as number of lines, and indicated in its header. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to review summary information about the type, source, and priority of queued incoming messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications, a user might need notification only of urgent messages, and rely on periodic review to deal with routine messages. Summary information about queued incoming messages should help guide message review. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>864 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/9 Information about Queued Messages</span></text>
</content>
<name>5.5/9</name>
<script></script>
</card>
card_226791.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a message (or other data transmission) arrives in a format incompatible with system decoding and/or device capabilities, advise the intended recipient to take some appropriate action that will not destroy the message itself or any other data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some instances a recipient might be able to resolve a format problem by changing the device destination specified for a particular message. Failure of message delivery should not disrupt any other work of the intended recipient. For example, the arrival of some message with an unrecognized format, or the attempted delivery of a graphic message at a text-only terminal, should not cause any system failure. Such an undeliverable message might be saved in a system file for subsequent disposition. Or that message (or some notification) might be returned to its sender. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If the user of an alphanumeric terminal should receive a message that includes nondisplayable graphic symbols, then the computer might notify the user and offer partial display of the readable portions of the message. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.4/6 Saving Undelivered Messages6.0/4 Protection from Interference by Other Users6.0/17 Warning Users of Potential Data Loss</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>863 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/8 Warning of Incompatible Format</span></text>
</content>
<name>5.5/8</name>
<script></script>
</card>
card_226364.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify "filters" based on message source, type, or content, that will control what notification is provided for incoming messages. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish the arrival of all messages from a particular source to produce a special notification of some sort. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/7 Flexible User Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>862 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/7 Filters for Message Notification</span></text>
</content>
<name>5.5/7</name>
<script></script>
</card>
card_226142.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where incoming messages will have different degrees of urgency, i.e., different implications for action, notify recipients of message priority and/or other pertinent information. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If incoming messages are queued so that their arrival will not interrupt current user tasks, which is a good idea, then users should be advised when an interruption is in fact necessary. Notification of urgent messages might be routed to a special area of a user's working display for immediate reference, whereas notification of routine messages might be deferred, or perhaps routed to a printer for more leisurely review at the user's convenience. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/7 Assignment of Priority</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>861 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/6 Indicating Priority of Received Messages</span></text>
</content>
<name>5.5/6</name>
<script></script>
</card>
card_225922.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For messages arriving while a user is logged on to a system, ensure that notification of message arrival will not interfere with that user's other information handling tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An incoming message should not preempt a user's working display. Instead, the computer might indicate message arrival by an advisory notice in a portion of the display reserved for that purpose. Review and disposition of received messages, like other transactions, should generally require explicit actions by a user. When an incoming message implies an urgent need for user attention, notify the user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 7.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/6 Control by Explicit User Action6.4/5 Nondisruptive Notification of Messages Received</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>860 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/5 Nondisruptive Notification of Arriving Messages</span></text>
</content>
<name>5.5/5</name>
<script></script>
</card>
card_225603.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users log on to a system, notify them of any data transmissions received since their last use of the system. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Depending on the application, a user might wish to know that some message has been received, or how many messages, or what kinds of messages. If automatic notification of received messages is not feasible, allow users to check for message arrival by requesting information from their general data processing system, without having to access some special message handling system for that purpose. At the least, a user should be able to find out how many new messages have arrived. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Bruder Moy Mueller Danielson 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>859 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/4 Message Notification at LOG-ON</span></text>
</content>
<name>5.5/4</name>
<script></script>
</card>
card_225500.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide default logic so that, unless otherwise specified by a user, the computer will route incoming messages automatically to a queue ("in-box"), pending subsequent review and disposition by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some computer buffering of received messages will be required for a user who is not logged on, and also to deal with near simultaneous receipt of multiple transmissions. The recommendation here is that the buffer queue for incoming transmissions be enlarged as necessary to permit indefinite retention of messages. Any queue will have limits, of course, and the user should be warned before those limits are exceeded. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For receiving messages, allow users to choose the method of receipt, i.e., what device (files, display, printer) will be the local destination. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Device destination might be specified differently for different types of messages, or for messages received from different sources. Transmitted data might be received directly into computer files. Incoming messages might be routed to an electronic display for quick review, and/or to a printer for hard-copy reference. If a specified receiving device is not operable, such as a printer that is not turned on, the computer should call that to the user's attention. When messages are received via display, provide queuing of incoming messages so that they will not interfere with use of that display for other information handling tasks. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For receiving messages, allow users to specify from what sources data are needed, and/or will be accepted. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Source specification might be in terms of data files, or other users, or external sources. Standard sources might be specified as a matter of routine procedure, with special sources designated as needed for particular transactions. Computer-mediated message handling offers the potential for screening out the electronic equivalent of "junk mail" or "crank calls". A user might choose to be selective in specifying the people or organizations from which messages will be received, or in specifying data categories of interest. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/7 Flexible User Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>856 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.5 Receiving Messages</span><span class="style21">5.5/1 Specifying Sources</span></text>
</content>
<name>5.5/1</name>
<script></script>
</card>
card_224744.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a log of data transmissions is required, maintain that log automatically, based on user specification of message types and record formats. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The objective here is to minimize routine "housekeeping" chores for the user. Once a user has specified the appropriate logging format (i.e., what elements of each message should be recorded), computer aids should generate the log automatically, either for all messages, or for specified categories of messages, or for particular messages identified by the user. The same kind of aids should be available for maintaining a journal of data transmissions, in applications where a full copy of each message is required. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/4 Minimal Memory Load on User5.0/5 Minimal User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>855 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/9 Automatic Record Keeping</span></text>
</content>
<name>5.4/9</name>
<script></script>
</card>
card_224369.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to recall any message whose transmission has been initiated, if it has not yet been received by its addressee(s). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The intent here is to allow users to change their minds, in situations where a message may have been sent by mistake. The difficulty of message recall will vary with the circumstances. If a message is still in the "out-box" (i.e., it has not yet actually been sent), then its recall can be accomplished simply by canceling the transmission request. If a message has been transmitted but not yet actually received (i.e., it still resides unread in a recipient's "in-box"), then perhaps it can still be retrieved. If a message is recalled before its intended recipient has seen it, that recipient need not be notified. If the recipient has seen it, then the sender should be notified that the message cannot be recalled. In that case, the message might be canceled or countermanded procedurally, by sending some follow-up message. If a message to several addressees has been seen by some recipients but not by others, then it would be subject only to partial recall; countermanding might be a better solution. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hannemyr Innocent 1985</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/12 Cancel Transmission</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>854 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/8 Message Recall</span></text>
</content>
<name>5.4/8</name>
<script></script>
</card>
card_224008.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If message transmission is not successful, notify the sender and if possible include an explanation of the problem. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It may help a user to know whether transmission has failed because of faulty addressing, or communication link failure, or some other reason, in order to take appropriate corrective action. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>853 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/7 Notification of Transmission Failure</span></text>
</content>
<name>5.4/7</name>
<script></script>
</card>
card_223792.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If message transmission is not successful, provide automatic storage of undelivered messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Transmission failure should not cause loss or destruction of messages, and should not disrupt the sender's work in any other way. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In the event of transmission failure, provide automatic queuing to preserve outgoing messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic queuing and retransmission of outgoing messages will reduce the need for user attention. If transmission fails in repeated attempts, however, then user intervention may be required, and some notification of that problem should be given to the user. If transmission fails because of faulty addressing, the user should be notified immediately. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that only one copy of any message will be transmitted to any individual addressee. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Receiving multiple copies of the same message can be confusing to a user, and will impose an unnecessary burden on the review and disposition of received messages. The problem of duplicative message transmission might arise if the same address should appear in both the TO and COPY fields of a message header, or appear once explicitly and again in some added distribution list(s). Thus one way to avoid message duplication is to ensure only a single appearance of each address in a message. If that is not practicable, then checking logic should be provided to transmit a single message to duplicated addresses. If for any reason a user did want to send multiple copies of a message to a single recipient, that should be specified explicitly in message transmission, rather than being accomplished by duplicate addressing. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.2/17 Single Occurrence of Address</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>850 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/4 Send Single Copy</span></text>
</content>
<name>5.4/4</name>
<script></script>
</card>
card_223219.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify what feedback should be provided for routine message transmission, and also to request specific feedback for particular messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users may wish to specify minimal feedback (or perhaps none at all) for routine message transmissions. On the other hand, users may wish to request more specific feedback for transmission of critical messages, as an electronic equivalent of registered mail. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/11 Return Receipt</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>849 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/3 User Specification of Feedback</span></text>
</content>
<name>5.4/3</name>
<script></script>
</card>
card_222805.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic feedback for data transmission confirming that messages have been sent or indicating transmission failures, as necessary to permit effective user participation in message handling. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Specific information requirements will vary with the application, but some feedback should be provided. Users might require notification only of exceptional circumstances, as in the event of transmission failure after repeated attempts. For the electronic equivalent of registered mail, it might be helpful to provide the sender confirmation that a message has been successfully transmitted, or possibly even to notify the sender when a recipient has actually read (displayed) the message. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>848 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/2 Automatic Feedback</span></text>
</content>
<name>5.4/2</name>
<script></script>
</card>
card_222628.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that transmitted data are protected automatically with parity checks to detect and correct any errors that may occur, and buffering until acknowledgment of receipt. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The computer should check transmitted data to determine whether an error has occurred; correct such errors automatically, if necessary by requesting retransmission; and call to the user's attention any case in which a detected error cannot be automatically corrected. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.4/1 Automatic Protection of Transmitted Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>847 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.4 Controlling Transmission</span><span class="style21">5.4/1 Automatic Protection of Transmitted Data</span></text>
</content>
<name>5.4/1</name>
<script></script>
</card>
card_222421.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to print copies of transmitted messages in order to make hard-copy records. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This may be regarded as a special case of message addressing, where a message is sent to a printer as well as to other people. User requirements for printed data are often unpredictable to system designers, and so a general printing capability should be provided. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In some applications, security constraints might make printed records inadvisable. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow senders to cancel a request for transmission of a message that has not yet been sent. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/3 CANCEL Option5.0/7 Flexible User Control5.4/8 Message Recall</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>845 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/12 Cancel Transmission</span></text>
</content>
<name>5.3/12</name>
<script></script>
</card>
card_221813.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide for message transmission with "return receipt requested" if users will require that capability. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The logic of what constitutes message "receipt" might vary from one application to another. Where sender and receiver share a common system, receipt might be defined as occurring when the recipient actually requests display of an incoming message. Where sender and receiver work with different (and perhaps dissimilar) message systems, receipt might be defined more tenuously. For example, a message might be considered "received" when the recipient is merely notified of its arrival, or opens an "in-box" permitting potential access to that message. Any "registered mail" of this kind should be labeled as such for all recipients of this mail. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.4/3 User Specification of Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>844 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/11 Return Receipt</span></text>
</content>
<name>5.3/11</name>
<script></script>
</card>
card_221630.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify a date and time for transmitting prepared messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should be able to cancel such a deferred transmission prior to its specified initiation time. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>843 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/10 Transmission at Specified Date/Time</span></text>
</content>
<name>5.3/10</name>
<script></script>
</card>
card_221254.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to defer the transmission of prepared messages, to be released by later action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user might wish to defer data transmission until a batch of related messages has been prepared, or perhaps until some specified date-time for release. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Prepared messages might be left in some "outbox" file for subsequent transmission when a user has finished an entire batch. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic queuing of outgoing messages, in order to reduce the need for user involvement in the routine processing of data transmission. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Specific requirements will vary with the application, but some queuing should be provided. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The computer might queue outgoing messages when communication channels to some addressees are temporarily unavailable, and then initiate transmission automatically when a link can be established. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/4 Minimal Memory Load on User</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>841 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/8 Automatic Queuing for Transmission</span></text>
</content>
<name>5.3/8</name>
<script></script>
</card>
card_220779.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When messages will have different degrees of urgency, i.e., different implications for action by their recipients, allow the sender of a message to designate its relative priority, or else have the computer assign priority automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The computer might impose limits on the priority that any particular user can assign to messages. In a military system, for example, only certain users might be authorized to send messages at the highest priority levels. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.5/6 Indicating Priority of Received Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>840 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/7 Assignment of Priority</span></text>
</content>
<name>5.3/7</name>
<script></script>
</card>
card_220590.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a message is sent, the computer should append to it fields showing the sender's address, and the date and time of message creation and/or transmission. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Recipients will generally need to know the origin of any received message. For some messages, a simple identification of the sender may be sufficient. In special situations, however, it may be necessary to provide special procedures for authenticating a sender's identity. For some applications, recipients must know when a message was created, in order to assess the currency of its contents. For other applications, users may need to know when a message was transmitted; its time of creation might not be important. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Like other formatting recommendations, this guideline would not apply when data transmission may be accomplished without formal messages, i.e., transmission by direct linking (where no formal headers are prepared) or by file transfer (where header information might be sent as a separate message rather than incorporated in the transmitted data file). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 §ice 1981</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.4/6 Authenticating Message Sources</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>839 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/6 Sender Identification</span></text>
</content>
<name>5.3/6</name>
<script></script>
</card>
card_220348.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users access to status information concerning the identity of other system users currently on-line, and the availability of communication with external systems. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such information may influence a user's choice of destinations and choice of communication methods, as well as the decision when to initiate transmission. For example, a user might choose to link directly with another user who is currently on-line, but might compose a message for deferred transmission to an inactive user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Dzida 1981</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.1/6 Other Users4.1/8 External Systems</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>838 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/5 Information About Communication Status</span></text>
</content>
<name>5.3/5</name>
<script></script>
</card>
card_219920.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When standard messages must be transmitted, as when a computer is monitoring external events and reporting data change, provide computer aids to initiate transmission automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic transmission of routine messages will reduce user workload and help ensure timely reporting. However, users should be able to monitor automatic message initiation, and may sometimes wish to modify initiation logic. Appropriate review/change procedures should be provided, perhaps under control of a system administrator. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Many operations-monitoring tasks might benefit from automatic generation of messages to report routine events. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>837 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/4 Computer-Initiated Transmission</span></text>
</content>
<name>5.3/4</name>
<script></script>
</card>
card_219875.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For sending messages, allow users to choose whether to transmit a displayed version or to transmit directly from computer-stored data files. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Message transmission from displays will permit a user to review and edit messages before sending them. But users might sometimes wish to transmit a prepared message directly, without having first to display that message for review. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When computer aids are provided for preparing, addressing, and initiating message transmission, allow users to review and change messages prior to transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.4/2 User Review of Data Before Transmission</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>835 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/2 User Review Before Transmission</span></text>
</content>
<name>5.3/2</name>
<script></script>
</card>
card_219370.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to initiate data transmission directly, by entering an explicit SEND command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some routine reporting situations it might help to initiate message transmission automatically. More often, however, users will wish to initiate transmission themselves. User control of initiation could permit a user to review and edit prepared messages before sending them, and possibly catch some mistakes before they are propagated. In applications where message review is critical (perhaps for purposes of security), users might be required to take some extra CONFIRM action to release data for transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/6 Control by Explicit User Action5.0/7 Flexible User Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>834 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.3 Initiating Transmission</span><span class="style21">5.3/1 User-Initiated Transmission</span></text>
</content>
<name>5.3/1</name>
<script></script>
</card>
card_218915.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to redistribute received messages by enlarging their address headers. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here redistribution is considered to be forwarding a message without editing or added comment, with only its address being changed. Where this capability is provided, some means must be adopted to indicate that a message has been forwarded verbatim, and to identify who added what names to the original distribution. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.1/11 Incorporate Other Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>833 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/19 Redistributing Received Messages</span></text>
</content>
<name>5.2/19</name>
<script></script>
</card>
card_218625.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications requiring coordinated review of messages by several recipients, allow the sender to specify a serial distribution so that a message will be passed from one recipient to the next. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Depending on the circumstances, serial recipients might or might not be allowed to annotate a forwarded message with comments. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.1/11 Incorporate Other Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>832 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/18 Serial Distribution</span></text>
</content>
<name>5.2/18</name>
<script></script>
</card>
card_218569.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the address of any particular recipient will occur only once in a message. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Duplicate addresses may confuse users. Within the limits of reasonable cost, computer checking should be provided to remove any address duplication that might result from the overlap of several expanded distribution lists, or from the cumulative listing of recipients of messages replying to replies. If duplicate addressing cannot reasonably be prevented, it is important to ensure that duplicate copies of a message are not actually sent to any recipient. There might be a special situation in which a user wants to send multiple copies of a message to a single recipient. In such a case, the extra copies should be specified explicitly in message transmission, rather than achieved indirectly by duplicating that recipient's address. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Deutsch 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.4/4 Send Single Copy</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>831 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/17 Single Occurrence of Address</span></text>
</content>
<name>5.2/17</name>
<script></script>
</card>
card_218265.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to edit the address fields in the header of a message being prepared for transmission. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An editing capability will allow users to correct errors, and to change unwanted addresses which may have been supplied automatically by the computer. Procedures for editing addresses should be the same as those for editing message content. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/3 Consistent Procedures5.1/1 Message Composition Compatible with Data Entry</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a user wishes to reply to a received message, provide the appropriate address(es) automatically, along with a reference to that received message. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The computer should address the reply to the sender of the original message, include some identification of the original message (e.g., its date, time, subject, and/or other identification), and should address copies of the reply to other recipients of the original message. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>829 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/15 Addressing Replies to Messages Received</span></text>
</content>
<name>5.2/15</name>
<script></script>
</card>
card_217747.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide computer checks for address accuracy (i.e., recognized content and format) and require users to correct mistakes before initiating message transmission. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A transmitted message should always have correct address information. In particular, a message sent to several people should have the correct address for all of those people on all copies. If the sender has specified a wrong address then no copies of the message should be sent until that error has been corrected. Otherwise, a recipient might attempt to reply using the same inaccurate addresses that were received, and address errors could propagate within the system. Ideally, address checking should occur as the user enters addresses, when correction may be relatively easy. If that is not possible, and an address error is not found until the user has moved on to some other task, then the user should not be interrupted to correct the error. Instead, a nonintrusive error message should be displayed, so that a correction can be made at the user's convenience. Sometimes an address error may not be discovered until a user has requested message transmission and logged off the system. In such a case, message transmission should be delayed until that user returns to the system, receives a delayed notification of the address error, and corrects it. That message delay is an acceptable consequence under these circumstances, i.e., when a user leaves the system right after making an error. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to enter a partial name when specifying addresses, if that will identify a particular destination uniquely. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a partial name is ambiguous (i.e., it partially identifies two or more addressees), then a list of the possible addressees might be provided and the user asked to select the correct one. The computer should automatically expand any partial address into its full form when completing the header for message transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>827 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/13 Automatic Expansion of Partial Addresses</span></text>
</content>
<name>5.2/13</name>
<script></script>
</card>
card_217178.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide computer aids to permit users to modify distribution lists once created. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users might sometimes wish to modify their stored distribution lists, or the distribution for any particular message. Appropriate review/change procedures should be provided. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/4 Minimal Memory Load on User5.0/5 Minimal User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>826 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/12 Modifying Distribution Lists</span></text>
</content>
<name>5.2/12</name>
<script></script>
</card>
card_217013.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Within a distribution list, allow users to include other distribution lists as well as individual names. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In providing this capability, note that care must be taken to ensure that computer expansion of nested lists will not cause continuous looping, as in a case where list A includes list B which in turn includes list A. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Deutsch 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>825 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/11 Lists Within Lists</span></text>
</content>
<name>5.2/11</name>
<script></script>
</card>
card_216630.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow individuals or groups to create their own informal distribution lists for local use. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such informal group and individual distribution lists should be expanded by the computer to show individual addressees prior to message transmission. As a procedural matter, informal distribution lists shared by a group might be created and maintained by some designated custodian, who could control access to such lists. Whereas any individual user's personal distribution lists might be changed freely. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Bruder Moy Mueller Danielson 1981Garcia-Luna Kuo 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>824 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/10 Informal Distribution Lists</span></text>
</content>
<name>5.2/10</name>
<script></script>
</card>
card_216363.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with information about distribution lists on which they are included, and about those distribution lists which they are authorized to use. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users should be able to discover the names of all people on distribution lists they are authorized to use. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Deutsch 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>823 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/9 Access to Distribution List Information</span></text>
</content>
<name>5.2/9</name>
<script></script>
</card>
card_216248.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide formal distribution lists recognized by the system so that users can specify multiple addresses with a single distribution list name. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Recognized system distribution lists need not be expanded to the names of individual addressees when a message is transmitted. The authority to use system distribution lists may be limited in some cases. For example, not everyone might be permitted to send messages to a distribution list of all employees in a large organization. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A formal distribution list might be maintained of people who are working on a particular project, or who are members of a particular organizational group. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Bruder Moy Mueller Danielson 1981Deutsch 1984Garcia-Luna Kuo 1981Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>822 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/8 System Distribution Lists</span></text>
</content>
<name>5.2/8</name>
<script></script>
</card>
card_216053.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to define nicknames for formal addresses, to save those nicknames in their own files, and to specify those nicknames when addressing messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">There are several implications to such a nickname capability. First, a user might wish to assign nicknames to computers and other devices (e.g., printers) as well as to people. Second, if a user defines a nickname, the computer must check to ensure that the nickname is unique in that user's nickname file. Third, nicknames must take precedence over system names when a user addresses a message; i.e., the computer must check the user's nickname file before checking the system-wide address list. Fourth, nicknames should not be transmitted; i.e., the computer should automatically transform nicknames into standard system addresses when completing the address header for message transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>821 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/7 User-Assigned Nicknames for Addressing</span></text>
</content>
<name>5.2/7</name>
<script></script>
</card>
card_215638.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to extract selected addresses from a directory for direct insertion into a header in order to specify the destination(s) for a message. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Direct insertion of addresses from a directory will avoid errors which a user might make in manual transcription and entry, as well as being faster. Users may also wish to extract addresses from the directory in order to build their own distribution lists, or add to a "nickname" file. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide computer aids so that a user can search an address directory by specifying a complete or partial name. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users will often remember a partial address, even if they cannot remember its complete form. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>819 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/5 Aids for Directory Search</span></text>
</content>
<name>5.2/5</name>
<script></script>
</card>
card_215063.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with a directory showing all acceptable forms of message addressing for each destination in the system, and for links to external systems. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In addition to the names of people, users may need to find addresses for organizational groups, functional positions, other computers, data files, work stations, and devices. The directory should include specification of system distribution lists as well as individual addresses. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Garcia-Luna Kuo 1981Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>818 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/4 Address Directory</span></text>
</content>
<name>5.2/4</name>
<script></script>
</card>
card_214786.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must specify the address for a message, provide prompting to guide the user in that process. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Prompting might consist of a series of questions to be answered, or an address form to be completed by the user, or reminders of command entries that may be needed. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/7 Prompting Entries5.0/4 Minimal Memory Load on User</text>
<text><span class="style10">Γêå Statement</span><span class="style1">For addressing and identifying messages, provide a basic set of header fields that can be interpreted by all systems to which users will send messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In any particular system, it should be possible for users (or a system administrator) to specify additions to the standard header fields in order to convey more descriptive information about different types of messages. Possible additions to the basic address fields might include SUBJECT, KEYWORDS, and REFERENCES. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Basic header fields might include DATE, TO, FROM, COPIES, and perhaps some message identification number. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Deutsch 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>816 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/2 Standard Address Header</span></text>
</content>
<name>5.2/2</name>
<script></script>
</card>
card_214480.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify the destination(s) to which data will be transmitted. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Specification of message destination might be in terms of system users, as individuals or groups, or other work stations and terminals (including remote printers), or users of other systems. Standard destinations may be specified as a matter of routine procedure, with special destinations designated as needed for particular transactions. For most applications, it is important that users be able to send a message to multiple destinations with a single transmission action. For multiple recipients, it will usually be helpful to show all addresses to all recipients, so that they will know who else has received the message. In some cases, however, it may be desirable to permit transmission of "blind" copies. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In some bus communication systems, it might be desirable to permit content-driven communication, where potential recipients can request all messages on particular topics, whether or not those messages are specifically addressed to them. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/7 Flexible User Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>815 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.2 Addressing Messages</span><span class="style21">5.2/1 Destination Selection</span></text>
</content>
<name>5.2/1</name>
<script></script>
</card>
card_214269.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to save draft messages during their preparation, or upon their completion. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should not be forced to recreate a message if its preparation is interrupted for some reason. Users should be able to specify how to save draft messages (i.e., in what file), just as they may decide how to save copies of transmitted and received messages. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to prepare messages of any length. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In particular, data transmission facilities should not limit the length of a message to a single display screen or to some fixed number of lines. There will usually be some implicit limit on message length imposed by storage capacity or the amount of time it would take to transmit a very long message. However, a user might sometimes choose to increase storage or accept transmission delays in order to send a long message required by a particular task. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to incorporate other messages in a message being prepared for transmission. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish to forward with comments a message received from someone else. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>812 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/11 Incorporate Other Messages</span></text>
</content>
<name>5.1/11</name>
<script></script>
</card>
card_213368.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to incorporate an existing data file in a message, or to combine several files into a single message for transmission. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It should not be necessary for a user to re-enter for transmission any data already entered for other purposes. It should be possible to combine stored data with new data when preparing messages for transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/1 Data Entered Only Once5.0/5 Minimal User Actions</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with flexible means for specifying the data to be transmitted. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When preparing a message, a user may wish to specify data to be included in the message by selecting a particular file, either all or a designated part, or by defining a data category. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/7 Flexible User Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>810 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/9 Flexible Data Specification</span></text>
</content>
<name>5.1/9</name>
<script></script>
</card>
card_212906.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In preparing tabular or graphic data for transmission, allow users to enter, review, and change data in customary formats, regardless of what the computer-imposed format will be for actual transmission purposes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Tabular data in messages should be prepared (and later received) in row-column format, even though the table entries might actually be transmitted as a coded string of data items. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/3 Consistent Procedures5.5/12 User Review of Messages in Queue</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>809 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/8 Tables and Graphics</span></text>
</content>
<name>5.1/8</name>
<script></script>
</card>
card_212591.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In preparing data forms for transmission, allow users to enter, review, and change data on an organized display with field labels, rather than requiring users to deal with an unlabeled string of items. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">User composition and review of unlabeled data strings, especially those requiring delimiters to mark items, will be prone to error. If such data strings are needed for economy of transmission, they should be generated by the computer automatically from data entered in a form-filling dialogue. Transmission of data from one computer to another will often be more economical if field labels and other display formatting features are omitted. In such cases, a format code should be included with the message, so that forms filled by the sender can be re-created in a display useful to the receiver. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/3 Consistent Procedures5.5/12 User Review of Messages in Queue</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>808 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/7 Data Forms</span></text>
</content>
<name>5.1/7</name>
<script></script>
</card>
card_212443.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When transmitted text must be formatted in a particular way, format control should be automatic with no extra attention required from the user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Header/paging formats might be inserted automatically in preparing text for transmission. Defined message formats might be filled automatically from stored text. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/21 Establishing Predefined Formats5.0/5 Minimal User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>807 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/6 Automatic Text Formatting</span></text>
</content>
<name>5.1/6</name>
<script></script>
</card>
card_212092.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data must be transmitted in a particular format, as in data forms or formatted text, provide computer aids to generate the necessary format automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When transmitting data, a user should not have to convert those data from whatever format was used originally for data entry. It is not sufficient merely to provide computer checking of formats generated by the user. Computers should help users to avoid errors, and not just to identify errors. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When message formats should conform to a defined standard or are predictable in other ways, provide prestored forms to aid users in message preparation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It may also be desirable to allow users to modify stored forms for their own purposes, and to define and store their own message forms. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A stored form might be used to create a routine report for transmission to a standard distribution list. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to compose and transmit messages as unformatted text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Allowing users to create arbitrary text messages (sometimes called "chatter") will let users deal flexibly with a variety of communication needs not anticipated by system designers. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>804 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/3 Unformatted Text</span></text>
</content>
<name>5.1/3</name>
<script></script>
</card>
card_211306.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When required message formats will vary unpredictably, allow users to compose and transmit messages with a format of their own design. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Establishing new formats, particularly if automatic data validation must be defined for specified fields, may require special skills. Therefore this capability might be provided to a system administrator and not to all system users. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that procedures for composing messages are compatible with general data entry procedures, especially those for text editing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should not have to learn procedures for entering message data that are different from more general data entry, particularly if those procedures might involve conflicting habits. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In systems where special editing capabilities are available for special tasks, as in some programming systems, users should be able to choose whether a special computer editor will be used for message preparation. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.0/3 Consistent Procedures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>802 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.1 Preparing Messages</span><span class="style21">5.1/1 Message Composition Compatible with Data Entry</span></text>
</content>
<name>5.1/1</name>
<script></script>
</card>
card_210812.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide software capabilities to annotate transmitted data with appropriate highlighting to emphasize alarm/alert conditions, priority indicators, or other significant second-order information that could affect message handling. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Second-order information, i.e., data about data, will often aid the handling and interpretation of messages. Such annotation might be provided automatically by software logic (e.g., a computer-generated date-time-stamp to indicate currency), or might be added by the sender of a message to emphasize some significant feature (e.g., attention arrows), or by the receiver of a message as an aid in filing and retrieval. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>801 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/10 Message Highlighting</span></text>
</content>
<name>5.0/10</name>
<script></script>
</card>
card_210475.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications requiring general-purpose message handling, provide users with flexible capabilities for filing copies of draft messages during preparation, transmitted messages, and received messages, and organizing those message files. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For most information handling systems, it is probably desirable to design the user interface so that users do not have to concern themselves with the detailed structure of data files. For message handling, however, users will often need to decide themselves whether and where to store transmitted data, i.e., how messages should be organized in their filing. Appropriate computer aids should be provided for message storage and retrieval, to permit naming of message files, grouping of files into larger "folders", and indexing the resulting file structure. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>800 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/9 Flexible Message Filing</span></text>
</content>
<name>5.0/9</name>
<script></script>
</card>
card_210234.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to interrupt message preparation, review, or disposition, and then resume any of those tasks from the point of interruption. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3 Interrupt</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>799 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/8 Interrupt</span></text>
</content>
<name>5.0/8</name>
<script></script>
</card>
card_210090.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide for flexible control of data transmission, so that users can decide what data should be transmitted, when, and where. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Flexible control of message handling will help ensure that routine data transmissions will not interfere with a user's other activities. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In monitoring and operation control applications, data transmission must often be event-driven. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Williamson Rohlfs 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>798 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/7 Flexible User Control</span></text>
</content>
<name>5.0/7</name>
<script></script>
</card>
card_209704.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the data transmission procedures so that both sending and receiving messages are accomplished by explicit user action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic message generation and receipt will be helpful in many applications, but in such cases the user should be able to monitor transmissions, and should be able to participate by establishing, reviewing and/or changing the computer logic that controls automatic data transmission. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action3.0/5 Control by Explicit User Action4.0/2 Explicit User Actions6.0/9 Control by Explicit User Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>797 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/6 Control by Explicit User Action</span></text>
</content>
<name>5.0/6</name>
<script></script>
</card>
card_209543.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the data transmission procedures to minimize required user actions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In some applications, software logic might prepare and transmit messages automatically, derived from data already stored in the computer. Software logic might provide automatic reformatting of stored data for transmission, where format change is required. Interface software might provide automatic insertion into messages of standard header information, distribution lists, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>796 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/5 Minimal User Actions</span></text>
</content>
<name>5.0/5</name>
<script></script>
</card>
card_209369.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the data transmission procedures to minimize memory load on the user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Interface software might provide automatic insertion into messages of standard header information, distribution lists, etc. The computer should provide automatic queuing of outgoing messages pending confirmation of transmission, and of incoming messages pending their review and disposition. Software might provide automatic record keeping, message logging, status displays, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>795 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/4 Minimal Memory Load on User</span></text>
</content>
<name>5.0/4</name>
<script></script>
</card>
card_209114.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that procedures for preparing, sending and receiving messages, are consistent from one transaction to another, and are consistent with procedures for other information handling tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Procedures should be the same for handling different kinds of messages and for messages sent to different destinations, although procedures for handling high-priority messages might incorporate special actions to ensure special attention. Users should be able to use the same procedures to enter, edit and display messages as they use to enter, edit and display other kinds of data. Computer-generated error messages and other forms of user guidance should also be consistent from one kind of information handling to another. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Data transmission that does not involve formal messages might by-pass standard procedures as in the direct linking of terminals, or might require special procedures as in the transfer of data files. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/1 Standard Procedures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>794 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/3 Consistent Procedures</span></text>
</content>
<name>5.0/3</name>
<script></script>
</card>
card_208803.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose functional wording for the terms used in data transmission -- for preparing and addressing messages, for initiating and controlling message transmission and other forms of data transfer, and for receiving messages -- so that those terms will match users' work-oriented terminology. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In general, a user should not have to learn the technical details of communication protocols, codes for computer "handshaking", data format conversion, etc., but should be able to rely on the computer to handle those aspects of data transmission automatically. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user should be able to address messages to other people or agencies by name, without concern for computer addresses, communication network structure and routing. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that data transmission functions are integrated with other information handling functions within a system. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should be able to transmit data using the same computer system (and procedures) used for general entry, editing, display, and other processing of data. A user should not have to log off from a general data processing system and log on to some other special system in order to send or receive a message. If data transmission facilities are in fact implemented as a separate system, that separation should be concealed in user interface design, so that a user can move from general information handling to message handling without interruption. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>792 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA TRANSMISSION</span><span class="style20">5.0 General</span><span class="style21">5.0/1 Functional Integration</span></text>
</content>
<name>5.0/1</name>
<script></script>
</card>
card_208199.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When changes are made to interface design, including changes to user guidance functions and on-line documentation, inform users of those changes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An on-line "message board" appearing at LOG-ON may suffice to notify users of current changes. But more extensive measures may be needed, including corresponding changes to user guidance information, e.g., prompts, error messages, HELP displays, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Limanowski 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>791 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.6 Design Change</span><span class="style21">4.6/2 Notifying Users of Design Changes</span></text>
</content>
<name>4.6/2</name>
<script></script>
</card>
card_208080.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When user guidance requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to user guidance functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">User guidance functions that may need to be changed include those represented in these guidelines, namely, changes in status information, routine and error feedback, job aids, and user records. Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below. In some applications, it may prove helpful to allow individual users to reword and/or add their own notes to on-line guidance material, just as they might annotate paper documentation. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Limanowski 1983</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.3/12 Documenting Error Messages4.4/3 Logical Menu Structure4.4/20 Dictionary of Abbreviations4.4/27 Synonyms for Standard Terminology4.5/3 Transaction Records4.5/4 Data Access Records4.5/5 Records of Program Use4.5/6 Error Records4.5/7 HELP Records</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>790 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.6 Design Change</span><span class="style21">4.6/1 Flexible Design for User Guidance</span></text>
</content>
<name>4.6/1</name>
<script></script>
</card>
card_207703.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a capability for recording user requests for HELP. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">HELP records can be used to detect deficiencies in in early system development, and can be used to improve user guidance in later system operation. In effect, user requests for HELP might be regarded as a possible symptom of poor interface design. If HELP requests are frequent for a particular transaction, then some design improvement may be needed, in procedures, or prompting for user guidance, or both. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">There is probably no need to record user browsing of HELP information, if such a capability is provided. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/23 HELP4.4/29 Browsing HELP</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>789 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/7 HELP Records</span></text>
</content>
<name>4.5/7</name>
<script></script>
</card>
card_207541.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a capability for recording user errors. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Error recording might be done continuously, or by periodic sampling under the control of a system administrator. Error records can be used to indicate supplemental instruction needed by different users, if individual user errors are identified. In that case, ethical considerations (and in some instances legal considerations) dictate that users be informed that such records will be kept. Error records can be used to indicate whether particular transactions are giving trouble to many users, in which case design improvements to the user interface may be needed, including changes to user guidance. For an individual user, the computer might be programmed to generate a special on-line HELP sequence to guide the correction of repeated errors. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 5.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.5/2 Notifying Users4.6/1 Flexible Design for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>788 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/6 Error Records</span></text>
</content>
<name>4.5/6</name>
<script></script>
</card>
card_207124.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer can maintain records of use for different portions of application software. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some cases "program calls" can be derived from transaction records rather than having to be measured directly. Records of software use may not affect user interface design directly, but can help detect and correct programming inefficiencies and improve system response, particularly during early stages of system development. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>787 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/5 Records of Program Use</span></text>
</content>
<name>4.5/5</name>
<script></script>
</card>
card_207054.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer can maintain records of data access, i.e., which data files, categories, or items have been called out for display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Records of data use may help software designers improve file structure, reduce data access time, and manage multiple use of shared data files. Data access records may also be required for purposes of data protection/security. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.2/8 Automatic Records of Data Access</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>786 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/4 Data Access Records</span></text>
</content>
<name>4.5/4</name>
<script></script>
</card>
card_206761.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer can maintain records of user transactions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Record keeping might include duration, sequencing and frequency of different transactions. Such transaction records will aid task analysis, particularly in developing systems where data handling requirements are not yet fully defined. A buffered store of current transactions may be required for user guidance, and for other purposes such as supporting an UNDO capability. In some applications, transaction recording might be made optional, under control of a system administrator. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/22 Record of Past Transactions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>785 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/3 Transaction Records</span></text>
</content>
<name>4.5/3</name>
<script></script>
</card>
card_206430.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Inform users of any records kept of individual performance. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Informing users concerning the nature and purpose of performance records is required by ethical principle, and in some situations may be required by law. Recording individual performance is potentially subject to abuse, and requires careful scrutiny to ensure essential protection of user privacy. Designers must conform to whatever legal (or otherwise agreed) restrictions may be imposed in this regard. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>784 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/2 Notifying Users</span></text>
</content>
<name>4.5/2</name>
<script></script>
</card>
card_206244.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where skilled user performance is critical to system operation, provide automatic computer recording and assessment of appropriate user abilities. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Recording individual performance may be constrained by other considerations, as noted elsewhere in this section. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/32 Adaptive Training</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>783 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.5 User Records</span><span class="style21">4.5/1 User Performance Measurement</span></text>
</content>
<name>4.5/1</name>
<script></script>
</card>
card_205970.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where a user must learn complex tasks, design computer-mediated training to adapt automatically to current user abilities. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Adaptive training will require some means for computer assessment of appropriate components of user performance. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/24 Flexible User Guidance4.5/1 User Performance Measurement</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>782 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/32 Adaptive Training</span></text>
</content>
<name>4.4/32</name>
<script></script>
</card>
card_205628.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Anticipate the needs of different users, and offer different levels of training for on-line job support. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In systems supporting different user jobs, on-line instruction might describe the procedures for each different data handling task. Instruction on keyboard use and lightpen selection of menu options might be provided for novice users, while a tutorial on command language might be provided for more experienced users. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/3 Control Matched to User Skill3.1/1 Dialogue Matched to Task and User3.1.3/35 By-Passing Menu Selection with Command Entry3.1.5/4 Layered Command Language4.0/24 Flexible User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>781 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/31 Flexible Training</span></text>
</content>
<name>4.4/31</name>
<script></script>
</card>
card_205322.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where appropriate, provide an on-line training capability to introduce new users to system capabilities and to permit simulated "hands on" experience in data handling tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">On-line simulation, using the same hardware, user interface software and data processing logic as for the real job, can prove an efficient means of user training. Care must be taken, however, to separate the processing of simulated data from actual system operations. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Permit users to browse through on-line HELP displays, just as they would through a printed manual, to gain familiarity with system functions and operating procedures. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cohill Williges 1985</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>779 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/29 Browsing HELP</span></text>
</content>
<name>4.4/29</name>
<script></script>
</card>
card_204992.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When an initial HELP display provides only summary information, provide more detailed explanations in response to repeated user requests for HELP. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is necessarily a matter of judgment just what information should be provided in response to a HELP request. Designing the HELP function to provide different levels of increasing detail permits users to exercise some judgment themselves as to just how much information they want. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 5.4 6.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.3/7 Multilevel Error Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>778 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/28 Multilevel HELP</span></text>
</content>
<name>4.4/28</name>
<script></script>
</card>
card_204577.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user requests HELP on a particular topic, the computer should accept synonyms for standard system terminology. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users will often attempt to get HELP for a function they know exists, but cannot remember its correct name. Likely synonyms can be identified by compiling a list of function names used in other similar systems. Other synonyms can be discovered through user testing. It might be desirable to let HELP facilities grow to meet user needs by allowing a system administrator to add synonyms to the system. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a DELETE command exists, then an explanation of that command might be displayed when a user requests HELP for ERASE. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>777 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/27 Synonyms for Standard Terminology</span></text>
</content>
<name>4.4/27</name>
<script></script>
</card>
card_204465.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a request for HELP is ambiguous in context, the computer should initiate a dialogue in which the user can specify what data, message or command requires explanation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The computer might ask a user to point at a displayed item about which HELP is requested. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>776 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/26 Clarifying HELP Requests</span></text>
</content>
<name>4.4/26</name>
<script></script>
</card>
card_204076.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Tailor the response to a HELP request to task context and the current transaction. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a data entry error has just been made, HELP should display information concerning entry requirements for that particular data item. If an error in command entry has just been made, HELP should display information concerning that command, its function, its proper structure and wording, required and optional parameters, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 6.3Magers 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>775 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/25 Task-Oriented HELP</span></text>
</content>
<name>4.4/25</name>
<script></script>
</card>
card_203952.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a simple, standard action that is always available to request HELP. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should be able to request HELP at any point in a transaction sequence. The procedure should always be the same, whether the user wants an explanation of a particular data entry, a displayed data item, or a command option. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">HELP might be requested by an appropriately labeled function key, or perhaps by keying a question mark into a displayed entry area. </span></text>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/24 Standard Action to Request HELP</span></text>
</content>
<name>4.4/24</name>
<script></script>
</card>
card_203643.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In addition to explicit aids (labels, prompts, advisory messages) and implicit aids (cueing), permit users to obtain further on-line guidance by requesting HELP. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is difficult for an interface designer to anticipate the degree of prompting that may be required to guide all users. Moreover, even when prompting needs are known, it may be difficult to fit all needed guidance information on a display page. One possibility would be to provide user guidance in a window overlay added to a working display when a user requests HELP. If more extensive user guidance is needed, then a separate, full-screen HELP display might be provided. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to request a displayed record of past transactions in order to review prior actions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.4/3 Record of Prior Entries4.5/3 Transaction Records</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>772 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/22 Record of Past Transactions</span></text>
</content>
<name>4.4/22</name>
<script></script>
</card>
card_203056.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When codes are assigned special meaning in a particular display, include a definition of those codes in the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will aid user assimilation of information, especially for display codes that are not already familiar. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 7.6.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/6 Definition of Display Codes</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>771 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/21 Definition of Display Codes</span></text>
</content>
<name>4.4/21</name>
<script></script>
</card>
card_202889.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a complete dictionary of abbreviations used for data entry, data display, and command entry, both for on-line user reference and in design documentation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In applications where users can create their own abbreviations, as in the naming of command "macros", it will be helpful to provide aids for users to create their own individual on-line dictionaries. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where a user can employ command entry, provide an on-line command index to guide user selection and composition of commands. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such a command index may help a user to phrase a particular command, and will also be generally helpful as a reference for discovering related commands and learning the overall command language. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where the user can choose what stored data to display, provide an on-line data index to guide user selection. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The data index should indicate file names, objects, properties, and other aspects of file structure that might be used to access different categories of data. It may help to allow users to specify what they require in this index. Some users might wish information on file size, currency (time of latest update), etc. Other users might wish to add a short description of each data file to remind themselves of its contents. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 6.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.6/3 Coherent Representation of Data Organization</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>768 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/18 Index of Data</span></text>
</content>
<name>4.4/18</name>
<script></script>
</card>
card_202044.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide reference material describing system capabilities and procedures available to users for on-line display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Many systems are not utilized effectively because users do not fully understand system capabilities. On-line access to a description of system structure, components and options will aid user understanding. On-line guidance can supplement or in some instances substitute for off-line training. An investment in designing user aids may be repaid by reduced costs of formal training as well as by improved operational performance. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">As the last step in generating a display output, ensure that the computer will automatically position the cursor so that it appears in a consistent display location for each type of transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent cursor positioning will provide an implicit cue for user guidance. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For data entry displays, the cursor should be placed initially at the first data field, or else at the first wrong entry if an error has been detected; in other displays, the cursor might be placed at a consistent HOME position, or at the first control option for menu selection, or else in a general command entry area, depending upon the type of display. </span></text>
<text>1.1/20 Consistent HOME Position1.1/21 Consistent Cursor Placement1.4/28 Automatic Cursor Placement3.2/6 Cursor Placement for Pointing at Options3.2/7 Cursor Placement for Keyed Entry of Options4.3/13 Cursor Placement Following Error</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide cues for data entry by formatting data fields consistently and distinctively. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent use of prompting cues can sometimes provide sufficient guidance to eliminate the need for more explicit advisory messages. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A colon might be used consistently to indicate that an entry can be made, followed by an underscored data field to indicate item size, such as </span><span class="style8">| Enter part code: __ __ __-__ __ | </span><span class="style1">or perhaps just simply </span><span class="style8">| Part code: __ __ __-__ __ | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.1.5Engel Granda 1975 § 6.3.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/10 Marking Field Boundaries1.4/11 Prompting Field Length1.4/12 Marking Required and Optional Data Fields1.4/18 Label Punctuation as Entry Cue</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>765 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/15 Cues for Prompting Data Entry</span></text>
</content>
<name>4.4/15</name>
<script></script>
</card>
card_201227.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In a transaction involving extended data entry, display a cumulative record of any previous inputs that are relevant to the current input. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a multipage data entry display, do not rely on the user to remember data accurately from one page to the next. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>764 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/14 Maintaining Context for Data Entry</span></text>
</content>
<name>4.4/14</name>
<script></script>
</card>
card_201124.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the results of a user entry depend upon context established by previous entries, display some indication of that context to the user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When the effects of user entries are contingent upon different operational modes, indicate the current mode. If the user is editing a data file, display both the file name and an indication of EDIT mode. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.1MIL-STD-1472C 1983 § 5.15.4.1.5 5.15.7.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.3/6 Labeling Display Freeze2.7.3/7 Signaling Changes to Frozen Data3.0/9 Displayed Context3.1.4/5 Labeling Multifunction Keys3.1.4/11 Indicating Active Function Keys3.4/1 Defining Context for Users3.4/4 Display of Operational Mode3.4/5 Display of Control Parameters4.1/5 Operational Mode4.2/8 Indicating Operational Mode</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>763 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/13 Displayed Context</span></text>
</content>
<name>4.4/13</name>
<script></script>
</card>
card_200958.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users vary in experience, which is often the case, provide prompting as an optional guidance feature that can be selected by novice users but can be omitted by experienced users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Flexibility in prompting can also be provided by multilevel HELP options, so that additional guidance information can be obtained if the simple prompt is not adequate. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Use concise wording for prompts; eliminate extraneous words. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Delete what: | </span><span class="style1">(Bad) </span><span class="style8">| What text would you like to delete: | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pakin Wray 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>761 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/11 Concise Wording of Prompts</span></text>
</content>
<name>4.4/11</name>
<script></script>
</card>
card_200354.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose a standard symbol for prompts indicating that an entry is required, and reserve that symbol only for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some standard prompting symbol in data entry forms, in menus, in command entry lines, etc., will help to cue users that an input is required. That standard symbol, used along with other formatting cues, will help to alert a user to differences between advisory messages and messages requiring an input. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Enter completion code: | </span><span class="style1">(Bad) </span><span class="style8">| Enter completion code | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.5.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/9 Standard Symbol for Prompting Entry3.1.3/15 Standard Symbol for Prompting Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>760 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/10 Standard Symbol for Prompting Entry</span></text>
</content>
<name>4.4/10</name>
<script></script>
</card>
card_199940.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use consistent phrasing and punctuation in all prompts. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Save as new file or Overwrite old file (S/O): |</span><span class="style1">and </span><span class="style8">| Create new file or Edit old file (C/E): | </span><span class="style1">(Bad) </span><span class="style8">| (S)ave as new file or (O)verwrite old file: | </span><span class="style1">and </span><span class="style8">| Would you like to create a new | | file or edit an old file (C/E): | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pakin Wray 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>759 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/9 Consistent Format for Prompts</span></text>
</content>
<name>4.4/9</name>
<script></script>
</card>
card_199723.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display prompts for data/command entry in a standard location, next to the command entry area at the bottom of the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As an alternative, prompts might be provided in a window overlay added to a working display at user request. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/6 Consistent Display Format2.7.5 Display Control Window Overlays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>758 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/8 Standard Display Location for Prompting</span></text>
</content>
<name>4.4/8</name>
<script></script>
</card>
card_199594.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide advisory messages and other prompts to guide users in entering required data and/or control parameters. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Prompting in advance of data/control entry will help reduce errors, particularly for inexperienced users. Prompting might be provided as an optional feature for skilled users. If a default value has been defined for null entry, that value should be included in the prompting information. </span></text>
<text>1.0/24 Prompting Data Entry1.8/4 Display of Default Values3.1.5/11 User-Requested Prompts3.2/11 Indicating Control Defaults3.5/5 Partial Execution of Stacked Commands</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>757 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/7 Prompting Entries</span></text>
</content>
<name>4.4/7</name>
<script></script>
</card>
card_199351.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If there are control options that are specifically appropriate to the current transaction, indicate those options on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Usually space can be found on a working display to remind users of several specific control options that are appropriate to the current transaction. A list of all available options, however, may well exceed display capacity. A user may be expected to remember general options, once they have been learned, without their specific inclusion in a display of guidance information. Perhaps the best design approach is to implement general options on appropriately labeled function keys, which will aid user learning and provide a continuing reminder of their availability. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Treat control options that are generally available at every step in a transaction sequence (PRINT, perhaps) as implicit options that need not be included in a display of specific current options. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">At every point in a transaction sequence, provide guidance telling the user how to continue. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Data are current through March 1986. | | Press STEP key to continue. | </span><span class="style1">(Bad) </span><span class="style8">| Data are current through March 1986. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When hierarchic menus are used, organize and label them to guide users within the hierarchic structure. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users will learn menus more quickly if a map of the menu structure is provided as HELP. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Billingsley 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/24 Labeling Grouped Options3.1.3/25 Hierarchic Menus for Sequential Selection3.1.3/30 Indicating Current Position in Menu Structure</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>754 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/4 Hierarchic Menus</span></text>
</content>
<name>4.4/4</name>
<script></script>
</card>
card_198238.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display menu options in logical groups. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Logical grouping of menu options will aid user learning and selection among displayed alternatives. It may be necessary to test proposed menus to determine just what structural groupings will seem logical to their intended users. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/23 Logical List Ordering3.1.3/22 Logical Grouping of Menu Options3.2/3 Organization and Labeling of Listed Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>753 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/3 Logical Menu Structure</span></text>
</content>
<name>4.4/3</name>
<script></script>
</card>
card_197895.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a general list (menu) of control options that is always available to serve as a "home base" or consistent starting point to begin a transaction sequence. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.1 4.4.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.5/12 General List of Commands3.2/2 General List of Control Options3.2/3 Organization and Labeling of Listed Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>752 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/2 General List of Control Options</span></text>
</content>
<name>4.4/2</name>
<script></script>
</card>
card_197702.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that specific user guidance information is available for display at any point in a transaction sequence. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not require a user to remember information not currently displayed. The user should not have to remember what actions are available, or what action to take next. Human memory is unreliable, and without guidance users can be expected to make errors. </span></text>
<text>2.0/3 Data Displayed in Usable Form2.7.2/1 Integrated Display3.1.3/17 Complete Display of Menu Options3.1.3/18 Menu Options Dependent on Context3.2/4 Indicating Appropriate Control Options3.2/5 Prompting Control Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>751 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.4 Job Aids</span><span class="style21">4.4/1 Guidance Information Always Available</span></text>
</content>
<name>4.4/1</name>
<script></script>
</card>
card_197531.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For conditions requiring (or implying the need for) special user attention, code the alarms (or warning messages) distinctively. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will help ensure appropriate attention, even when a user is busy at routine tasks. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Alarm messages might be marked with a blinking symbol and/or displayed in red, and be accompanied by an auditory signal; warnings and error messages might be marked with a different special symbol and/or displayed in yellow. </span></text>
<text>2.6/12 Special Symbols2.6/32 Conventional Assignment of Color Codes2.6/35 Blink Coding2.6/40 Distinctive Auditory Coding3.6/2 Distinctive and Consistent Alarms6.0/17 Warning Users of Potential Data Loss</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>750 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.3 Error Feedback</span><span class="style21">4.3/19 Alarm Coding</span></text>
</content>
<name>4.3/19</name>
<script></script>
</card>
card_197310.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require the user to take some explicit action to confirm a potentially destructive data/command entry before the computer will execute it. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A requirement to take an explicit CONFIRM action will direct user attention to questionable entries and help the user avoid the consequences of thoughtless errors. What constitutes "potentially destructive" requires definition in the context of each system application. </span></text>
<text>3.5/7 User Confirmation of Destructive Entries6.0/18 User Confirmation of Destructive Actions6.0/20 Separate CONFIRM Action6.3/19 User Confirmation of Destructive Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>749 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.3 Error Feedback</span><span class="style21">4.3/18 User Confirmation of Destructive Entries</span></text>
</content>
<name>4.3/18</name>
<script></script>
</card>
card_196943.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a data or command entry seems doubtful, in terms of defined validation logic, display a cautionary message asking the user to confirm that entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Feedback to the user can be worded to deal with a range of intermediate categories between a seemingly correct entry and an outright error. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| Blood pH of 6.6 is outside the normal range; | | confirm or change entry. | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.7.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/8 User Warned of Potential Data Loss3.5/11 Preventing Data Loss at LOG-OFF</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>748 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.3 Error Feedback</span><span class="style21">4.3/17 Cautionary Messages</span></text>
</content>
<name>4.3/17</name>
<script></script>
</card>
card_196749.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that a displayed error message is removed after the error has been corrected; do not continue to display a message that is no longer applicable. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The immediate removal of an error message upon error correction will serve as feedback to a user that the corrected entry is indeed correct. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Following error detection, require the user to re-enter only that portion of a data/command entry which is not correct. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The user should not have to rekey an entire command string or data set just to correct one wrong item. </span></text>
<text>3.1.5/23 Correcting Command Entry Errors3.5/3 Prompting Command Correction6.0/10 User Review and Editing of Entries6.3/10 Editing Entries After Error Detection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>746 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.3 Error Feedback</span><span class="style21">4.3/15 User Editing of Entry Errors</span></text>
</content>
<name>4.3/15</name>
<script></script>
</card>
card_196253.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When an entry error has been detected, continue to display the erroneous entry, as well as an error message, until corrections are made. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The error itself may provide useful information, in conjunction with the error message, helping a user understand the specific nature of the error. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In addition to providing an error message, mark the location of a detected error by positioning the cursor at that point on the display, i.e., at that data field or command word. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Displaying the cursor at a non-routine position will help emphasize that an error has occurred, and direct the user's attention to the faulty entry. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">As a supplement to on-line guidance, include in the system documentation a listing and explanation of all error messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Developing good error messages may require review by both designers and users. Documentation of the complete set of error messages will facilitate such review. Documentation of error messages will permit users to reference particular messages for fuller explanation, and to review all messages as a means of understanding data processing requirements and limitations. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Display an error message approximately 2-4 seconds after the user entry in which the error is detected. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Longer delays in error feedback may cause user uncertainty or confusion. Longer delays may also cause frustration if the user is already aware of the error, which is often the case. Shorter delays in error feedback can pose problems of a different sort. An error message following immediately upon a user entry can be disconcerting. Immediate error feedback can also be irritating. User expectations are conditioned by human conversation, where an immediate contradiction is considered rude, and where a polite listener will pause for a few moments before saying that you are wrong. If error messages take somewhat longer to appear than the routine computer response, then that additional delay may cue the user to expect an error message and pay attention to it. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For type-ahead systems with experienced users, error messages should be displayed as quickly as possible. </span></text>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.3 Error Feedback</span><span class="style21">4.3/11 Appropriate Response Time for Error Messages</span></text>
</content>
<name>4.3/11</name>
<script></script>
</card>
card_195197.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">The computer should display an error message only after a user has completed an entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In general, the display of error messages should be timed so as to minimize disruption of the user's thought process and task performance. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">An error message should not be generated as wrong data are keyed, but only after an explicit ENTER action has been taken. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a user repeats an entry error, there should be some noticeable change in the displayed error message. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If an error message is repeated identically, so that displayed feedback seems unchanged, the user may be uncertain whether the computer has processed the revised entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A simple expedient might be to display the same verbal message but with changing annotation, perhaps marked with either one asterisk or two. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When multiple errors are detected in a combined user entry, notify the user, even though complete messages for all errors cannot be displayed together. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The computer should place the cursor in the data field referred to by the displayed error message, with other error fields highlighted in some way, e.g., by reverse video. There should also be some means for the user to request sequential display of the other error messages if needed. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| DATE should be numeric. | | + 2 other errors | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Following the output of a simple error message, permit users to request a more detailed explanation of the error. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A more complete discussion of each error could be made available on-line, perhaps at several levels of increasing detail, supplemented by reference to off-line system documentation if necessary. Successively deeper levels of explanation might then be provided in response to repeated user requests for HELP. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.6 5.4Engel Granda 1975 § 3.3</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt neutral wording for error messages; do not imply blame to the user, or personalize the computer, or attempt to make a message humorous. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Error messages should reflect a consistent view that the computer is a tool, with certain limitations that a user must take into account in order to make the tool work properly. If error messages reflect an attitude that the computer (or its programmer) imposes rules, or establishes "legality", the user may feel resentful. If error messages reflect personalization of the computer, as if it were a friendly colleague, a naive user may be misled to expect human abilities the machine does not actually possess. If error messages are worded humorously, any joke will surely wear thin with repetition, and come to seem an intrusion on a user's concern with efficient task performance. The same considerations apply for the wording of computer-generated prompts and other instructional material. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Entry must be a number. | </span><span class="style1">(Bad) </span><span class="style8">| Illegal entry. | </span><span class="style1">(Bad) </span><span class="style8">| I need some digits. | </span><span class="style1">(Bad) </span><span class="style8">| Don't be dumber, use a number. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Make error messages brief but informative. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Often a user will recognize that an error has been made, and the message will serve merely as a confirming reminder. In such instances, short error messages will be scanned and recognized more quickly. For a user who is truly puzzled, and who needs more information than a short error message can provide, auxiliary HELP can be provided either on-line or by reference to system documentation. If an on-line HELP explanation is not available, a user may have to refer to system documentation for a coded listing of possible errors. Under those circumstances, some designers display each error message with an identifying code, to facilitate rapid reference to documentation. That practice might help experienced users, who would gradually come to recognize the codes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Entry must be a number. | </span><span class="style1">(Bad) </span><span class="style8">| Alphabetic entries are not acceptable because | | this entry will be processed automatically. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a data entry or (more often) a control entry must be made from a small set of alternatives, an error message that is displayed in response to a wrong entry should indicate the correct alternatives. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt wording for error messages which is appropriate to a user's task. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Error messages that can be understood only by experienced programmers (and interface designers) will have no value for ordinary users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Contract number not recognized; check | | the file and enter a current number. | </span><span class="style1">(Bad) </span><span class="style8">| Entry blocked. Status Flag 4. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Make the wording of error messages as specific as possible. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Specificity will require computer analysis of data processing transactions in context. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| No record for Loan 6342; check number. | </span><span class="style1">(Bad) </span><span class="style8">| No record for inquiry. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When the computer detects an entry error, display an error message to the user stating what is wrong and what can be done about it. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users should not have to search through reference information to translate error messages. Error messages can be regarded as the most important form of system documentation. Well designed error messages will give help to users automatically, at the point where help is most needed. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Code format not recognized; enter two letters, | | then three digits. | </span><span class="style1">(Bad) </span><span class="style8">| Invalid input. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Following user interrupt of data processing, display an advisory message assuring the user that the system has returned to its previous status. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/6 RESTART Option</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>731 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.2 Routine Feedback</span><span class="style21">4.2/11 Feedback for User Interrupt</span></text>
</content>
<name>4.2/11</name>
<script></script>
</card>
card_192287.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user selects a displayed item in order to perform some operation on it, highlight that item on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will provide a routine natural feedback that item selection has been accomplished, and will provide a continuing reminder to the user of just what selection has been made. Highlighting might be accomplished in different ways. Reverse video is commonly employed for this purpose. For a selection among displayed options, the selected option might be brightened. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.1.1 3.1 3.1.1MIL-STD-1472C 1983 § 5.15.5.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/5 Fast Acknowledgement of Entry3.1.3/9 Feedback for Menu Selection3.4/6 Highlighting Selected Data</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When previously selected options are still operative, display those options either automatically or on user request. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Displaying a cumulative sequence of option selections may help a novice user learn transaction sequences, and may help any user deal with complex transactions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/13 Displayed Context4.4/22 Record of Past Transactions</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a user (or computer) action establishes a change in operational mode that will affect subsequent user actions, display some continuing indication of current mode. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice is particularly helpful when the mode selected is one seldom used. Display of mode selection will help prevent unintended data loss when the mode is potentially destructive (e.g., DELETE). For destructive modes, it may help if the mode indication is implemented as some sort of distinctive change in the appearance of the cursor, since the cursor is probably the one display feature most surely seen by a user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Selection of a DELETE mode in text editing should produce some kind of warning signal on the display, perhaps by a distinctive change in cursor shape. </span></text>
<text>3.4/4 Display of Operational Mode3.4/5 Display of Control Parameters4.1/5 Operational Mode4.4/13 Displayed Context6.0/15 Explicit Action to Select Destructive Modes6.0/16 Feedback for Mode Selection</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When lists or data tables extend beyond the capacity of a single display frame, inform the user that the display is continued in multiple frames. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As a complementary recommendation, it may also be desirable to conclude completed lists with the annotation | End of list | unless the list is so short that it obviously does not fill available display space. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In special formats such as spreadsheets the partial nature of a display may be self-evident. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Incomplete lists might be annotated at the bottom as </span><span class="style8">| Continued on next page | </span><span class="style1">For extended data tables, the display title might be annotated as </span><span class="style8">| Page ____ of ____ |</span><span class="style1"> For scrolled data, displays might be annotated with the current and concluding locations </span><span class="style8">| Line ____ of ____ | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a unique identification for each display in a consistent location at the top of the display frame. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A displayed title may suffice, although a shorter identification code may be helpful for some purposes. The objective is to help the user recognize a display when it appears, to learn interactive sequences stepping from one display to another, and (in some system applications) to request a particular display directly. Display identification will also help both users and interface designers to refer to individual displays in discussion and documentation. In applications involving menu selection, it may prove helpful to code each display with the string of option selections (letter codes) used to reach that display. This practice is particularly useful in situations where a user can learn to by-pass the menu selection sequence by entering option string codes as a single command to request a familiar data display. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">As a possible exception, interface designers may sometimes provide unlabeled displays as "free-form" screens for text entry and other tasks involving display composition by users. </span></text>
<text>2.5/10 Display Title at Top2.7.1/2 Display Identification Labels2.7.1/3 Meaningful Display Labels2.7.1/4 Consistent Format for Display Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>726 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.2 Routine Feedback</span><span class="style21">4.2/6 Display Identification</span></text>
</content>
<name>4.2/6</name>
<script></script>
</card>
card_191016.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When user requests for printed output will be handled by a remote printer, give the user an advisory message confirming that a print request is being processed. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.14</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/29 Information on Printing Status</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>725 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.2 Routine Feedback</span><span class="style21">4.2/5 Feedback for Print Requests</span></text>
</content>
<name>4.2/5</name>
<script></script>
</card>
card_190942.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When computer processing of a user entry has been delayed, inform the user when processing is completed, and provide appropriate guidance for further user actions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For long delays, interim feedback on processing status before completion may be reassuring to a user. Such follow-up messages, however, should not interfere with current user activities. It may be desirable to reserve a special display window for prompts and advisory messages. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide some indication of transaction status whenever the complete response to a user entry will be delayed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">After making an entry to the computer, the user needs feedback to know whether that entry is being processed properly. Delays in computer response longer than a few seconds can be disturbing to the user, especially for a transaction that is usually processed immediately. In such a case some intermediate feedback should be provided, perhaps as an advisory message that processing has been initiated, and ideally with an estimate of how long it will take to complete. Indicating the progress of computer processing is particularly important when response time is inconsistent and may be lengthy, which is often the case when users perform complex functions on time-shared systems. Displaying time-to-completion or some other indication of progress will permit users to plan their time more effectively, and perhaps to perform other tasks while waiting. Note that a routine advisory (e.g., </span><span class="style8">| Wait for processing |</span><span class="style1">) displayed before every computer response, whether fast or slow, is not an effective indication of transaction status. Users will come to ignore routine messages that are sometimes true but sometimes just false alarms. </span></text>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.2 Routine Feedback</span><span class="style21">4.2/3 Feedback for Control Entries</span></text>
</content>
<name>4.2/3</name>
<script></script>
</card>
card_190361.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that computer response to user entries will be rapid, with consistent timing as appropriate for different types of transactions. </span></text>
<text>1.1/5 Fast Acknowledgement of Entry2.7.1/6 Fast Response to Display Request3.0/18 Appropriate Computer Response Time3.1/2 Appropriate Computer Response Time</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>722 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.2 Routine Feedback</span><span class="style21">4.2/2 Fast Response</span></text>
</content>
<name>4.2/2</name>
<script></script>
</card>
card_190105.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that every input by a user will consistently produce some perceptible response output from the computer; when a terminal is in use, its display screen should never be blank. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Keyed entries should appear immediately on the display. Function key activation or command entries should be acknowledged either by evident performance of the requested action, or else by an advisory message indicating an action in process or accomplished. Inputs that are not recognized by the computer should be acknowledged by an error message. Absence of system response is not an effective means of signaling acceptable entry. At best, a dialogue without feedback will be disconcerting to the user, as when we talk to an unresponsive human listener. At worst, the user may suspect system failure, with consequent disruption and/or termination of the interaction sequence. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">A user might choose to blank a display screen temporarily, perhaps to protect data from casual onlookers, but even then some acknowledging message should probably appear, e.g.,</span><span class="style8"> | Display temporarily suppressed. | </span></text>
<text>1.0/3 Feedback During Data Entry1.0/12 Feedback for Completion of Data Entry1.0/13 Feedback for Repetitive Data Entries3.0/14 Feedback for Control Entries3.0/16 Compatibility with User Expectations3.1.3/9 Feedback for Menu Selection3.1.4/10 Feedback for Function Key Activation6.2/6 Display Suppression for Security</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>721 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.2 Routine Feedback</span><span class="style21">4.2/1 Consistent Feedback</span></text>
</content>
<name>4.2/1</name>
<script></script>
</card>
card_189736.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When alarm signals are established on the basis of logic defined by users, permit users to obtain status information concerning current alarm settings, in terms of dimensions (variables) covered and values (categories) established as critical. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Alarm status information will be particularly helpful in monitoring situations where responsibility may be shifted from one user to another ("change of watch"). </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.6/1 Alarm Definition by Users</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>720 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/10 Alarm Settings</span></text>
</content>
<name>4.1/10</name>
<script></script>
</card>
card_189614.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When task performance requires or implies the need to assess currency of information, annotate displays with date-time signals. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Depending on the application date-time status might be displayed continuously or periodically on displays that are automatically updated, or by user request. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>719 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/9 Date and Time Signals</span></text>
</content>
<name>4.1/9</name>
<script></script>
</card>
card_189349.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When task performance requires data exchange and/or interaction with other systems, allow a user to obtain relevant status information for external systems. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/5 Information About Communication Status</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>718 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/8 External Systems</span></text>
</content>
<name>4.1/8</name>
<script></script>
</card>
card_188940.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When task performance is affected by operational load (e.g., number of on-line users), allow a user to obtain status information indicating current system performance, expressed in terms of computer response time. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It may be necessary to define a "standard" function for which computer response time is predicted on a normalized basis. Such load information is primarily helpful, of course, when system use is optional, i.e., when a user can choose to defer work until low-load periods. But load status information may help in any case by establishing realistic user expectations for system performance. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>717 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/7 System Load</span></text>
</content>
<name>4.1/7</name>
<script></script>
</card>
card_188708.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When task performance requires data exchange and/or interaction with other users, allow a user to obtain status information concerning other people currently using the system. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If there are many other users, it might be helpful to allow a user to ask whether any particular individual is a current user. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.3/5 Information About Communication Status</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>716 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/6 Other Users</span></text>
</content>
<name>4.1/6</name>
<script></script>
</card>
card_188655.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the results of user action are contingent upon different operational modes, then clearly indicate the currently selected mode. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A change in display caption and/or cursor shape might suffice to alert users to changing modes. </span></text>
<text>3.4/4 Display of Operational Mode4.2/8 Indicating Operational Mode4.4/13 Displayed Context</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>715 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/5 Operational Mode</span></text>
</content>
<name>4.1/5</name>
<script></script>
</card>
card_188369.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If at any time the keyboard is locked, or the terminal is otherwise disabled, notify the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An auditory signal will be especially helpful to touch-typists, who may be looking at source documents for data entry rather than at the display or keyboard. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Control lockout might be signaled by disappearance of the cursor from the display, or by a notable change in the shape of the cursor, accompanied by an auditory signal. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/20 Indicating Control Lockout</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>714 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/4 Keyboard Lock</span></text>
</content>
<name>4.1/4</name>
<script></script>
</card>
card_188005.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user tries to log onto a system and LOG-ON is denied because of system unavailability, display an advisory message to tell the user what the system status is and when the system will become available. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Avoid "as soon as possible" messages. Make an estimate of system availability, and update the estimate later if that becomes necessary. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| System is down for maintenance until 9:30 AM. | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.3.5</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>713 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/3 LOG-ON Delay</span></text>
</content>
<name>4.1/3</name>
<script></script>
</card>
card_187732.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users must log on to a system, display appropriate prompts for LOG-ON procedures automatically at a user's terminal; do not require users to take any special action to obtain a LOG-ON display, other than turning on the terminal. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An automatic LOG-ON display will signal the operational availability of a terminal, as well as prompting the user to make necessary initial inputs. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.6.1Engel Granda 1975 § 4.2.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/3 Separate LOG-ON Procedure</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>712 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/2 Automatic LOG-ON Display</span></text>
</content>
<name>4.1/2</name>
<script></script>
</card>
card_187639.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide some indication of system status to users at all times. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications, system status may be continuously displayed. Status display can be explicit (e.g., by message), or can be implicit (e.g., by a displayed clock whose regular time change offers assurance that the computer link is still operating). Alternatively, system status information might be provided only on user request, following a general or specific query. Status information is particularly needed, of course, when system operation is unreliable for any reason. Under those conditions, if status information is not provided by design, users will often devise their own repertoire of harmless but time-wasting inputs to test system performance. When system status changes, it may be desirable for the computer to generate an advisory message to draw users' attention to that change. </span></text>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.1 Status Information</span><span class="style21">4.1/1 Indicating Status</span></text>
</content>
<name>4.1/1</name>
<script></script>
</card>
card_187222.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If computer-generated speech is used to provide warnings as well as other forms of user guidance, ensure that spoken warnings are easily distinguishable from routine messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications, computer-generated speech might be useful for providing a few short and simple warnings. However, if speech output is also used for other purposes, then the warning messages must be distinctive. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Speech output used to identify dangerous conditions might use some distinctive voice (perhaps female rather than male, or vice versa) and/or preface each warning message with some other distinctive auditory signal. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hakkinen Williges 1984Simpson etal 1985Simpson Williams 1980</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When using computer-generated speech to provide messages, ensure that those messages are short and simple. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a user does not understand a written message, s/he can reread it. That is not the case with spoken messages. Though a REPEAT function might be provided, a better solution is to restrict use of speech outputs for short and simple messages. If a user who may not be watching a display must be given long or complex messages, it is probably better to provide a simple auditory signal such as a chime, and then display the messages visually for the user to read. In general, users will understand complex messages better when they see them displayed than when they hear them. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Thomas Rosson 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>709 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/28 Simple Spoken Messages</span></text>
</content>
<name>4.0/28</name>
<script></script>
</card>
card_186636.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Limit computer-generated speech to provide only a few messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When messages are spoken, the user must remember each message. If many different messages are given one after another, then a user would probably not remember them all, and might only remember one or two. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As negative examples, computer-generated speech would not be useful if many messages might be given at one time, or for conveying a lengthy list of menu options. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>708 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/27 Limited Number of Spoken Messages</span></text>
</content>
<name>4.0/27</name>
<script></script>
</card>
card_186457.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider computer-generated speech output for user guidance messages in environments with low ambient noise, when a user's attention may not be directed toward a visual display or when providing a visual display is impractical. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A noisy environment, particularly noise from other voices, will make it difficult for a user to hear computer-generated speech. Auditory signals such as computer-generated speech are useful for notifying a user of important information when his/her attention is focused somewhere other than a visual display, such as when a touch-typist transcribes data from a paper form. Speech output might also help a user who must access a computer from a remote location, by telephone. When considering speech output for user guidance, remember that people other than the user might hear those spoken messages. Speech output may prove distracting to other people trying to work nearby. Or the user of a system may not wish others to hear his/her messages, as might be the case if spoken messages were provided for an automated banking application. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Computer-generated speech might be used to provide prompts or status messages, including warnings. A familiar example of the use of computer-generated speech for warnings is the "talking dashboard", which tells a car driver when a door is open, or when the car requires service. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Thomas Rosson 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>707 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/26 Speech Output</span></text>
</content>
<name>4.0/26</name>
<script></script>
</card>
card_186151.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to switch easily between any information handling transaction and its associated guidance material. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If user guidance is difficult to obtain, and/or if asking for guidance will disrupt a current transaction (e.g., erase a working display), then users will prefer to guess at proper procedures rather than seeking help. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Guidance might be displayed as a temporary "window" overlay on the working display, which a user could request or suppress at will. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Limanowski 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>706 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/25 Easy Ways to Get Guidance</span></text>
</content>
<name>4.0/25</name>
<script></script>
</card>
card_185870.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When techniques adopted for user guidance (display of option lists, command prompting, etc.) may slow an experienced user, provide alternative paths or modes permitting a user to by-pass standard guidance procedures. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Multiple paths, such as command entry to by-pass a menu, or use of abbreviated rather than complete commands, can speed the performance of an experienced user. The interface designer, however, should take care that such shortcuts supplement rather than supplant the standard, fully guided procedures provided for novice users. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/2 Minimal User Actions4.4/31 Flexible Training4.4/32 Adaptive Training</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>705 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/24 Flexible User Guidance</span></text>
</content>
<name>4.0/24</name>
<script></script>
</card>
card_185607.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Be consistent in grammatical construction when wording user guidance. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Even minor inconsistencies can distract a user, and delay comprehension as the user wonders momentarily whether some apparent difference represents a real difference. Consistent grammatical construction may help a user resolve an ambiguous message (e.g., </span><span class="style8">| Numeric entry |</span><span class="style1">) to understand whether it recommends an action (e.g., "You should enter a number") or indicates an error condition (e.g., "You entered a number when you shouldn't have"). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) (Bad) </span><span class="style8">| Options: | | Options: | | s = Select data | | s = Select data | | e = Erase display | | e = Erasure function | | w = Write file | | w = Write file | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When user guidance describes a sequence of steps, follow that same sequence in the wording of user guidance. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Enter LOG-ON sequence before running programs. | </span><span class="style1">(Bad) </span><span class="style8">| Before running programs, enter LOG-ON sequence. | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/18 Temporal Sequence</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>703 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/22 Temporal Sequence</span></text>
</content>
<name>4.0/22</name>
<script></script>
</card>
card_185154.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt active rather than passive voice in user guidance messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sentences in active voice are easier to understand. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Clear the screen by pressing RESET. | </span><span class="style1">(Bad) </span><span class="style8">| The screen is cleared by pressing RESET. | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/17 Active Voice</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>702 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/21 Active Voice</span></text>
</content>
<name>4.0/21</name>
<script></script>
</card>
card_184947.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt affirmative rather than negative wording for user guidance messages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Affirmative statements are easier to understand. Tell the user what to do rather than what to avoid. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Clear the screen before entering data. | </span><span class="style1">(Bad) </span><span class="style8">| Do not enter data before clearing the screen. | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.3 5.3.9</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/16 Affirmative Sentences</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>701 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/20 Affirmative Statements</span></text>
</content>
<name>4.0/20</name>
<script></script>
</card>
card_184634.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose wording for user guidance that speaks directly to a user, rather than talking about users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Press ENTER to continue. | </span><span class="style1">(Bad) </span><span class="style8">| The user should press ENTER to continue. | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pakin Wray 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>700 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/19 Speaking Directly to Users</span></text>
</content>
<name>4.0/19</name>
<script></script>
</card>
card_184465.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose wording for user guidance that is consistent with the words used for control entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When selecting or composing control entries, a user will tend to mimic the vocabulary, format, and word order used in computer displays, including labels, error messages, HELP displays, etc. If displayed wording is consistent with required entries, a user will be more likely to make a correct entry on the first try. Consistent wording of user guidance will be particularly helpful for dialogues based on constrained natural language. If a designer begins by determining which words and formats users are likely to choose naturally, and then reinforces that usage by incorporating such wording in user guidance, much of a user's interaction with the computer will be predictable. Therefore, the "natural language" need not accommodate the full range of possible entries, but only those entries which users are likely to make. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| To delete a paragraph, press DELETE and then PARAGRAPH. |</span><span class="style1"> (Bad) </span><span class="style8">| To erase a paragraph, press DELETE and then PARAGRAPH. |</span><span class="style1"> If a user must complete a control form to specify printer settings, the words used as labels on that form should also be used in any error messages and HELP displays which may guide that process. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Good Whiteside Wixon Jones 1984Mooers 1983Zoltan-Ford 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/7 Display Consistent with Entry Requirements3.0/13 Wording Consistent with User Guidance3.1.7/1 Constrained Natural Language</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>699 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/18 Wording Consistent with Control Entry</span></text>
</content>
<name>4.0/18</name>
<script></script>
</card>
card_184092.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt task-oriented wording for labels, prompts and user guidance messages, incorporating whatever special terms and technical jargon may be customarily employed in the users' tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Jargon terms may be helpful, if they represent the jargon of the user and not of the designer or programmer. The rule here should be to know the users and adapt interface design to their vocabulary instead of forcing them to learn new wording. </span></text>
<text>1.4/22 Familiar Units of Measurement2.0/12 Familiar Wording3.1.5/6 Familiar Wording3.1.5/7 Consistent Wording of Commands3.2/9 Task-Oriented Wording for Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>698 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/17 Task-Oriented Wording</span></text>
</content>
<name>4.0/17</name>
<script></script>
</card>
card_183929.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When wording labels, prompts and user guidance messages, adopt terminology familiar to users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">User testing and iterative design will often be needed to eliminate difficult words, abbreviations and acronyms that are not generally familiar to all users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Data requires special access code; | | call Data Base Admin, X 9999. | </span><span class="style1">(Bad) </span><span class="style8">| IMS/VS DBMS private data; see DBSA, 0/99-99. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the names for function keys, command names, etc., are consistent for similar or identical functions in different transaction sequences. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistency in interface design is the fundamental basis of effective user guidance. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, do not call the same function EDIT in one place, MODIFY in another, UPDATE in a third. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.7.2Engel Granda 1975 § 4.2.9</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/10 Consistent Terminology for Sequence Control3.1.3/12 Option Wording Consistent with Command Language3.1.3/14 Consistent Coding of Menu Options3.1.3/19 Consistent Display of Menu Options3.1.5/7 Consistent Wording of Commands</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>696 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/15 Consistent Wording</span></text>
</content>
<name>4.0/15</name>
<script></script>
</card>
card_183429.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that codes and abbreviations for data entry/display conform to conventional usage and user expectations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Conventional usage will aid user learning of codes, and reduce the likelihood of user error in code generation (entry) and code interpretation (display). Deviation from familiar meanings, such as using an aircraft symbol to denote artillery and vice versa, would almost certainly confuse users. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.7.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/5 Familiar Coding Conventions2.6/32 Conventional Assignment of Color Codes</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>695 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/14 Familiar Coding Conventions</span></text>
</content>
<name>4.0/14</name>
<script></script>
</card>
card_183048.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that symbols and other codes have consistent meanings from one display to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will aid user learning of new codes, so that they will gain familiarity. Where codes have special meanings, those should be defined in the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.6.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/7 Consistent Coding Across Displays2.6/16 Establishing Standards for Shape Coding2.6/32 Conventional Assignment of Color Codes3.1.3/13 Letter Codes for Menu Selection4.4/21 Definition of Display Codes</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>694 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/13 Consistent Coding Conventions</span></text>
</content>
<name>4.0/13</name>
<script></script>
</card>
card_183011.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Whatever methods are used to highlight critical items in data display, adopt similar methods to highlight the display of critical user guidance information. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Alarms and warning messages may require output of auxiliary auditory signals as well as display highlighting, to help assure that they attract the user's attention. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.1MIL-STD-1472C 1983 § 5.15.3.3.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/1 Highlighting Critical Data3.6/2 Distinctive and Consistent Alarms4.3/17 Cautionary Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>693 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/12 Highlighting Critical User Guidance</span></text>
</content>
<name>4.0/12</name>
<script></script>
</card>
card_182684.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Label all displayed data clearly. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Labels for individual data fields can be omitted only where display format and labeling of grouped data clearly identify subordinate items, as in row/column labeling of tabular data. </span></text>
<text>1.4/5 Data Field Labels1.4/19 Informative Labels1.4/20 Data Format Cueing in Labels1.4/21 Labeling Units of Measurement1.4/23 Alternative Units of Measurement1.5/3 Informative Labels2.2/3 Data Field Labeling</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>692 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/11 Clear Data Labels</span></text>
</content>
<name>4.0/11</name>
<script></script>
</card>
card_182327.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Label function keys and other controls clearly to indicate their function. </span></text>
<text>1.0/10 ENTER Key Labeling3.1.4/4 Distinctive Labeling of Function Keys</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>691 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/10 Clear Control Labels</span></text>
</content>
<name>4.0/10</name>
<script></script>
</card>
card_182040.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design cursors (in terms of shape, blink, or other means of highlighting) so that they are readily distinguished from other displayed items. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When a cursor is automatically positioned under computer control, it can serve to direct the user's attention to a particular point on a display, and so it should be designed to catch the eye. Even when the cursor has been positioned by a user, if the user is momentarily distracted then a distinctive format may help locate the cursor. A cursor is the most immediate and continuously available form of user guidance, since it will generally mark the current focus of user attention. With this in mind, the interface designer may decide to use different cursor formats to denote different operational conditions. If that is done, each of those different cursors should be distinctive from other displayed items, and from each other. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design display formats so that user guidance material is readily distinguishable from displayed data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent location of user guidance on the display will usually suffice, but other formatting conventions may help distinguish particular categories of user guidance, such as labels, prompts, etc., as recommended in other guidelines. </span></text>
<text>1.4/16 Distinctive Label Format1.5/2 Distinctive Labels2.2/8 Distinctive Label Format2.5/2 Distinctive Display Elements3.1.3/20 Menus Distinct from Other Displayed Information3.1.4/17 Distinctive Location</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>689 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/8 Distinctive Format for User Guidance</span></text>
</content>
<name>4.0/8</name>
<script></script>
</card>
card_181661.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Format each different type of user guidance consistently across displays. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Types of user guidance include display titles, labeling of data entry fields, prompts for data/command entry, error messages, alarms, status and other advisory messages, as well as on-line instructional material. Consistent allocation of particular areas of a display for user guidance may be sufficient. Certain types of guidance, however, such as alarms and error messages, may require auxiliary coding to help attract user attention. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Display titles might be centered at the top of the display, with display identification codes at the upper left corner. The bottom line of the display should be reserved for command entries, where needed, in which case the line just above it could be used for prompts and advisory messages. </span></text>
<text>1.4/17 Consistent Label Format2.5/11 Command Entry, Prompts, Messages at Bottom</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>688 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/7 Consistent Format for User Guidance</span></text>
</content>
<name>4.0/7</name>
<script></script>
</card>
card_181294.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Create display formats with a consistent structure evident to the user, so that any particular type of data is always presented in the same place and in the same way. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent display formats will help new users learn to interact efficiently with the system. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3MIL-STD-1472C 1983 § 5.15.3.1.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/24 Form Compatible for Data Entry and Display1.4/25 Form Compatible with Source Documents2.0/6 Consistent Display Format2.5/1 Consistent Format2.7.1/4 Consistent Format for Display Labels3.0/8 Distinctive Display of Control Information3.1.3/8 Standard Area for Code Entry3.1.3/32 Consistent Design of Hierarchic Menus3.1.5/2 Standard Display Area for Command Entry3.4/7 Consistent Display of Context Information4.4/8 Standard Display Location for Prompting</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>687 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/6 Consistent Display Format</span></text>
</content>
<name>4.0/6</name>
<script></script>
</card>
card_181032.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Tailor the display for any transaction to the current information requirements of the user, so that only relevant data are displayed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When this can be done successfully, so that only relevant data are displayed, the display itself provides implicit guidance, showing what data should be considered. Conversely, display of irrelevant data will tend to confuse the user. </span></text>
<text>2.0/1 Necessary Data Displayed2.0/2 Only Necessary Data Displayed2.7.2/1 Integrated Display</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>686 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/5 Only Necessary Information Displayed</span></text>
</content>
<name>4.0/5</name>
<script></script>
</card>
card_180763.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In general, follow recommendations for the design of data displays when designing user guidance displays. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some of the specific guidelines for data display are restated for convenient reference in this section, as particularly appropriate for display of user guidance. Many other applicable data display guidelines are cited by cross reference. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>685 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/4 Display of Guidance Information</span></text>
</content>
<name>4.0/4</name>
<script></script>
</card>
card_180606.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where users must log on to the system, design LOG-ON as a separate procedure that is completed before a user is required to select among any operational options. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Separate LOG-ON will focus user attention on the required input(s), without the distraction of having to anticipate other decisions, and will help reduce initial confusion, particularly for novice users. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.6.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>684 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/3 Separate LOG-ON Procedure</span></text>
</content>
<name>4.0/3</name>
<script></script>
</card>
card_180358.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take explicit actions to specify computer data processing; the computer should not take extra (and possibly unrecognized) actions beyond those specified by a user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Explicit actions, even though they may require an extra keystroke or two, will help a user to learn procedures and to understand better what is happening in any transaction. In effect, requiring the user to take action to accomplish something can be regarded as a form of guidance. An interface designer, with expert knowledge of the system and its internal workings, is sometimes tempted to provide the user with "smart shortcuts", where the computer will execute automatically some action that the user would surely need to take. Incorporating such smart shortcuts in interface design, though done with the intention of helping the user, will risk confusing any but the most expert users. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Automatic cross file updating following data change might be considered an exception to this rule. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.1.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action1.7/4 Deferral of Required Data Entry3.0/5 Control by Explicit User Action3.1.4/9 Single Activation of Function Keys3.2/1 User Control in Transaction Selection6.0/9 Control by Explicit User Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>683 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> USER GUIDANCE</span><span class="style20">4.0 General</span><span class="style21">4.0/2 Explicit User Actions</span></text>
</content>
<name>4.0/2</name>
<script></script>
</card>
card_180108.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design standard procedures for accomplishing similar, logically related transactions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Standard procedures will facilitate user learning and efficient system operation. A designer might argue that for one particular transaction a standard procedure does not seem efficient. Perhaps the standard procedure requires one or two more keystrokes than some special procedure that might be devised. But every special feature of interface design will put a small added burden on the user's memory, and where special procedures are not remembered they may not be used properly. Standard procedures will increase overall operational efficiency. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When sequence control requirements may change, which is often the case, provide some means for the user (or a system administrator) to make necessary changes to control functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sequence control functions that may need to be changed include those represented in these guidelines, namely, the types of dialogue that are provided, procedures for transaction selection and interrupt, methods for context definition and error management, and alarm control. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/1 Flexible Sequence Control3.1.3/28 Easy Selection of Important Options3.1.5/10 User-Assigned Command Names3.1.5/14 User Definition of Macro Commands3.2/18 User Definition of Macro Commands3.2/19 User-Specified Transaction Timing3.6/1 Alarm Definition by Users</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If users are required to acknowledge a special or critical alarm in some special way, ensure that such acknowledgment will not inhibit or slow remedial user response to the critical initiating condition. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not make acknowledgment of critical alarms too complicated. Help users deal with the cause of an alarm rather than the symptom. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>680 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.6 Alarms</span><span class="style21">3.6/5 Special Acknowledgment of Critical Alarms</span></text>
</content>
<name>3.6/5</name>
<script></script>
</card>
card_179259.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with a simple means of turning off an auditory alarm, without erasing any displayed message that accompanies the auditory signal. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Turning off an auditory alarm will ensure that any succeeding alarm condition will be able to generate a new auditory signal to attract the user's attention. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A function key labeled ALARM RESET would suffice for this purpose. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with a simple means of acknowledging and turning off non-critical alarm signals. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A function key labeled ALARM OFF would suffice for this purpose. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that alarm signals and messages are distinctive for each class of events. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users should participate in the classification of alarming events, and might help in specifying the desired nature of different alarm signals. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In monitoring and process control applications, allow users to define the conditions (in terms of variables and values) that will result in computer generation of alarm messages. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">There are some situations where alarm conditions must be predefined by functional, procedural, or perhaps even legal requirements, such as violation of aircraft separation in air traffic control. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The nurse in charge of an intensive care monitoring station might need to specify for each patient that a warning be signaled when blood pressure (a "variable") exceeds or falls below defined levels ("values"). </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to BACKUP easily to previous steps in a transaction sequence in order to correct an error or make any other desired change. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.7.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/4 BACKUP Option6.3/12 Flexible BACKUP for Error Correction</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a data entry transaction has been completed and errors detected, permit users to make corrections directly and immediately. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is helpful to correct data entry errors at the source, i.e., while a user still has the entry in mind and/or source documents at hand. When a user cannot correct an entry, as when transcribing from a source document that itself contains an error, it may help to allow the user to defer entry of the wrong item. Alternatively, the user might wish to cancel the transaction. For transactions involving extended entry of multiple items, computer checking might be invoked as each page or section of data is entered. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 5.7Pew Rollins 1975 § 2.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.7/6 Timely Validation of Sequential Transactions6.3/9 Immediate Error Correction</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a user requests LOG-OFF, check pending transactions and if any pending transaction will not be completed, or if data will be lost, display an advisory message requesting user confirmation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user may sometimes suppose that a job is done before taking necessary implementing actions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| Current data entries have not been filed; | | SAVE if needed, before confirming LOG-OFF. | </span></text>
<text>4.3/17 Cautionary Messages6.3/22 Preventing Data Loss at LOG-OFF</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>673 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.5 Error Management</span><span class="style21">3.5/11 Preventing Data Loss at LOG-OFF</span></text>
</content>
<name>3.5/11</name>
<script></script>
</card>
card_177570.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that any user action can be immediately reversed by an UNDO command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">UNDO itself should be reversible, so that a second UNDO action will do again whatever was just undone. Such an UNDO capability is currently available in many interface designs, and should be provided more generally. Even with an UNDO capability, however, a user may make an irretrievable mistake, if succeeding actions intervene before a prior destructive action is noticed. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user is overhasty in confirming a destructive action, and realizes the mistake right away (i.e., before taking another action), then an UNDO action might be taken to reverse the damage. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide an explicitly labeled CONFIRM function key, different from the ENTER key, for user confirmation of questionable control and data entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Confirmation should not be accomplished by pushing some other key twice. Some interface designers recommend that in special cases confirmation should be made more difficult still, e.g., by keying the separate letters C-O-N-F-I-R-M. Even such extreme measures, however, cannot guarantee that users will not make errors. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.4/3 Function Keys for Interim Control Entries3.1.4/4 Distinctive Labeling of Function Keys3.1.4/9 Single Activation of Function Keys3.1.4/14 Consistent Assignment of Function Keys6.0/19 Distinctive CONFIRM Action</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Word the prompt for a CONFIRM action to warn users explicitly of any possible data loss. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| CONFIRM deletion of entire AIRFIELD file?? |</span><span class="style1"> (Bad) </span><span class="style8">| CONFIRM DELETE | </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.5/25 Reviewing Destructive Commands4.3/17 Cautionary Messages6.0/17 Warning Users of Potential Data Loss</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>670 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.5 Error Management</span><span class="style21">3.5/8 User Warned of Potential Data Loss</span></text>
</content>
<name>3.5/8</name>
<script></script>
</card>
card_176645.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a control entry will cause any extensive change in stored data, procedures and/or system operation, and particularly if that change cannot be easily reversed, notify the user and require confirmation of the action before implementing it. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a user completes correction of an error, whether of a command entry or data entry, require the user to take an explicit action to re-enter the corrected material; use the same ENTER action for re-entry that was used for the original entry. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If only a portion of a stacked command can be executed, notify the user and provide appropriate guidance to permit correction, completion, or cancellation of the stacked command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Note that stacked commands can fail because of error in their composition, or for other reasons such as unavailability of required data. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If an error is detected in a stacked series of command entries, either consistently execute to the point of error, or else consistently require users to correct errors before executing any command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It may help the user if the commands are executed to the point of error, or it may not. In most applications, partial execution will probably prove desirable. The point here is that a considered interface design decision should be made and then followed consistently. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 5.6Pew Rollins 1975 § 4.7.3</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If an element of a command entry is not recognized, or logically inappropriate, prompt users to correct that element rather than requiring re-entry of the entire command. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A faulty command can be retained in the command entry area of the display, with the cursor automatically positioned at the incorrect item, plus an advisory message describing the problem. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to edit an extended command during its composition, by backspacing and rekeying, before taking an explicit action to ENTER the command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users can often recognize errors in keyed entries prior to final entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 5.4MIL-STD-1472C 1983 § 5.15.7.2Neal Emmons 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/2 Flexible Interrupt3.1.5/23 Correcting Command Entry Errors6.0/10 User Review and Editing of Entries6.3/8 Editing Data Before Entry</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design the interface software to deal appropriately with all possible control entries, correct and incorrect. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For certain routine and easily recognized errors, such as trying to tab beyond the end of a line, a simple auditory signal ("beep") may be sufficient computer response. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user selects a function key that is invalid for a particular transaction, no action should result except display of an advisory message indicating what functions are appropriate at that point. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.12.4.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.4/12 Disabling Unneeded Function Keys6.0/14 Safe Response to Random Inputs</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>663 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.5 Error Management</span><span class="style21">3.5/1 Appropriate Response to All Entries</span></text>
</content>
<name>3.5/1</name>
<script></script>
</card>
card_175052.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that information displayed to provide context for sequence control is distinctive in location and format, and consistently displayed from one transaction to the next. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a user is performing an operation on some selected display item, highlight that item. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will help avoid error, if a user has misunderstood or perhaps forgotten which item was selected. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to review any control parameter(s) that are currently operative. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A capability for parameter review is helpful even when a user selects all parameters personally. Users will sometimes be forgetful, or may become confused, particularly if their activities are interrupted for any reason. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A text processing system might display a variety of parameters to control document printing, including margin widths, line spacing, number of copies, etc., which would represent current default values that a user could review and change when desired. A system might display a "user profile" that specifies for a particular user which editor will be used, which message system, which general menu, what level of prompting, etc. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When context for sequence control is established in terms of a defined operational mode, remind users of the current mode and other pertinent information. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If text is displayed in an editing mode, then a caption might indicate EDIT as well as the name of the displayed text; if a DELETE mode is selected for text editing, then some further displayed signal should be provided. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Permit users to request a summary of the results of prior entries to help determine present status. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Summarizing prior entries will be particularly helpful in tasks where transaction sequences are variable, where a user must know what was done in order to decide what to do next. Summarizing prior entries may not be needed for routine transactions if each step identifies its predecessors explicitly, although even in those circumstances a user may be distracted and at least momentarily become confused. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In an aircraft assignment task, there might be a status display showing current commitments of aircraft to missions. In a text processing application, there might be a status display listing documents already edited and printed in the current work session. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.1/3 Recapitulating Prior Answers4.4/22 Record of Past Transactions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>658 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.4 Context Definition</span><span class="style21">3.4/3 Record of Prior Entries</span></text>
</content>
<name>3.4/3</name>
<script></script>
</card>
card_173655.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the sequence control software to interpret current control actions in the context of previous entries; do not require users to re-enter data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The software logic supporting contextual interpretation of control entries need not be perfect in order to be helpful. The computer may occasionally have to present an interpreted command for user review and approval. That is still easier for the user than having to specify every command completely in the first place. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If transactions involving contextual interpretation would have destructive effects (e.g., data deletion), then display the interpreted command first for user confirmation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If data have just been stored in a named file, permit users to request a printout of that file without having to re-enter its name. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design the sequence control software to maintain context for the user throughout the series of transactions comprising a task; where appropriate, display the results of previous entries affecting present actions, and indicate currently available options. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.8/9 User Review of Prior Entries3.0/9 Displayed Context4.4/13 Displayed Context</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a SUSPEND option is provided, display some indication of the SUSPEND status whenever that option is selected by a user, and at subsequent log-on prompt the user in those procedures that will permit resumption of the suspended transaction. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide a SUSPEND option which will have the effect of preserving current transaction status when a user leaves the system, and permitting resumption of work at that point when the user later logs back onto the system. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In the interests of data protection, a SUSPEND option might require special user identification procedures at subsequent log-on, to prevent unauthorized access to suspended transactions. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.1/8 Continuous Recognition of User Identity</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a PAUSE option is provided, display some indication of the PAUSE status whenever that option is selected by a user, and prompt the CONTINUE action that will permit resumption of the interrupted transaction. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide PAUSE and CONTINUE options which will have the effect of interrupting and later resuming a transaction sequence without any change to data entries or control logic for the interrupted transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A "security pause" may have to be implemented quickly and easily, which suggests that this option should be offered via function key. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish to interrupt a current task to read an incoming message. In the interests of data protection, as a "security pause", a user might wish to blank a current display to prevent its being read by some casual visitor. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.2/6 Display Suppression for Security</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide an END option which will have the effect of concluding a repetitive transaction sequence. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">END can be implemented by whatever means are appropriate to the dialogue design, i.e., by menu selection, command entry, or function key. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a repetitive sequence of data entries, where completing one transaction cycles automatically to begin the next, END might break the cycle and permit the user to select other transactions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.10</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>651 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.3 Interrupt</span><span class="style21">3.3/7 END Option</span></text>
</content>
<name>3.3/7</name>
<script></script>
</card>
card_172030.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide a RESTART option which will have the effect of canceling any entries that may have been made in a defined transaction sequence and returning to the beginning of the sequence; when data entries or changes will be nullified by a RESTART action, require users to CONFIRM the RESTART. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A RESTART action combines the functions of REVIEW and CANCEL, and is relevant only to well-defined transaction sequences. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a sequence of related data entries, on several display frames, RESTART might erase all data entries in the sequence and return to the first frame. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide a nondestructive REVIEW option which will have the effect of returning to the first display in a defined transaction sequence, permitting the user to review a sequence of entries and make necessary changes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">REVIEW is an extension of the BACKUP capability, and is useful only in well-defined transaction sequences such as step-by-step data entry in a question-and-answer dialogue. In some applications, REVIEW might be designed to include cancellation of any interim entries made in a pending transaction. More often, however, it will be better to preserve pending entries without processing. Interface design should be consistent in that regard. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a sequence of related data entries, on several display frames, REVIEW might return to the first frame, from which data could be reviewed and edited as needed throughout the sequence of frames. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide a nondestructive BACKUP option which will have the effect of returning to the display for the last previous transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such a BACKUP capability will prove feasible only in the software design of well-defined transaction sequences, but will prove helpful when it can be provided. In some applications, BACKUP might be designed to include cancellation of any interim entries made in a pending transaction. More often, however, it will be better to preserve pending entries without processing. Interface design should be consistent in that regard. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a sequence of related data entries, on several display frames, BACKUP might return to the previous frame, where data items could then be erased by CANCEL or could be edited individually. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.7.7Foley Van Dam 1982Foley Wallace 1974</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If appropriate to sequence control, provide a CANCEL option which will have the effect of erasing any changes just made by the user and restoring the current display to its previous version. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The easiest way to implement CANCEL may be simply to regenerate the current display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a sequence of related data entries, on several display frames, CANCEL might erase ("clear") data in the current frame as a convenient way to begin keying corrected data, rather than having to erase each data item individually. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If different kinds of user interrupt are provided, design each interrupt function as a separate control option with a distinct name. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, it would not be good design practice to provide a single INTERRUPT key which has different effects depending upon whether it is pushed once or twice; users would be confused by such an expedient and uncertain about what action has been taken and its consequences. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide flexibility in sequence control by allowing a user to interrupt or cancel a current transaction, in ways appropriate to task requirements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Provision of flexible interrupt capabilities will generally require some sort of suspense file or other buffering in software design. Some such capability, however, will be needed for other reasons, e.g., to allow users to correct mistaken entries, and to permit the computer to require user confirmation of potentially destructive entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 3.3.16 3.3.17</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>645 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.3 Interrupt</span><span class="style21">3.3/1 User Interruption of Transactions</span></text>
</content>
<name>3.3/1</name>
<script></script>
</card>
card_170404.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When appropriate to task requirements, allow users to specify transaction timing, i.e., when a requested transaction should start or should be completed, or the periodic scheduling of repeated transactions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications, of course, users will wish specified transactions performed as quickly as possible. In some applications, however, users may have good reasons to delay initiation (or completion) of transactions. In some instances, it may be possible to provide appropriate software logic to aid user decisions on transaction timing. For example, if a user requested a bulky printout, the computer might propose overnight printing as an economical alternative, subject to user confirmation. Allowing users to specify periodic scheduling for routine transactions will tend to reduce the memory load on users, and may help ensure more reliable system performance. If such routine transactions require further user inputs, as when preparing periodic activity reports, computer logic can be devised to prompt users on a timely basis to make the necessary entries. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish to specify that a requested data analysis routine be deferred until some later hour, to ensure that interim updates to the data will be taken into account. A user might prepare a number of messages for transmittal, but specify that actual transmission be deferred until a later time. A user might wish to specify that a request for a large printout be deferred to take advantage of reduced overnight rates, but specify a printout deadline to ensure delivery by 0800 the next morning. A user might wish to specify that summarized briefing material be prepared automatically at 0600 every morning until further notice. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide flexibility in transaction selection by allowing users to assign a single name to a defined series of control entries, and then use that named "macro" for subsequent command entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In this way users can make frequently required but complicated tasks easier to accomplish, when the interface designer has failed to anticipate a particular need. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Demers 1981Foley Wallace 1974</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.5/10 User-Assigned Command Names3.1.5/14 User Definition of Macro Commands</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>643 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/18 User Definition of Macro Commands</span></text>
</content>
<name>3.2/18</name>
<script></script>
</card>
card_169842.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If punctuation other than spaces is needed to separate entries in a stacked control entry, adopt a single standard symbol for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Whatever symbol is adopted as a delimiter for control entries should preferably be the same as any delimiter that might be used when making data entries. Note that even when a standard symbol is consistently used to punctuate stacked entries, entry will be slower and less accurate than if only spaces are used for punctuation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A slash (/) may be a good choice. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 6.2.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/4 Standard Delimiter Character3.1.5/16 Standard Delimiter</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>642 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/17 Standard Delimiter in Entry Stacking</span></text>
</content>
<name>3.2/17</name>
<script></script>
</card>
card_169600.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to stack control entries without any punctuation other than spaces between words or option codes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sometimes stacked entries may require specific symbols as delimiters for their interpretation. Careful design of command languages and/or option codes can minimize the need for delimiters to interpret correct entries. Delimiters may still be needed, however, to protect against possible user errors, i.e., stacked commands that have been improperly composed. Entry will be faster and more accurate when spaces are used rather than any other kind of punctuation. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For control entry stacking, accept command names or their abbreviations or option codes just as if those control entries had been made separately. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications, it might prove helpful if the computer were to display its interpretation of a stacked entry for user review and confirmation. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For control entry stacking, require entries to be in the same order as they would normally be made in a succession of separate control entry actions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 6.2.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>639 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/14 Consistent Order in Entry Stacking</span></text>
</content>
<name>3.2/14</name>
<script></script>
</card>
card_168730.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to key a sequence of commands or option codes as a single "stacked" control entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In particular, allow users to enter stacked entries from any menu so that an experienced user can make any specific control entry without having to view subsequent menus. Control entry stacking may be helpful when a user is being prompted to enter a series of parameter values, and knows what several succeeding prompts will request and what values to enter. Control entry stacking will permit a transition from simple step-by-step control entry by novice users, as in menu selection and question-and-answer dialogues, to the entry of extended command-language statements by experienced users; entry stacking is especially helpful in time-shared systems where computer response to any user entry may be slow. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">At any step in a defined transaction sequence, if there is only a single appropriate next step then provide a consistent control option to continue to the next transaction. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If data entry is involved, then require a user to take an explicit ENTER action to signal data entry, rather than simply selecting CONTINUE. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">CONTINUE or NEXT or STEP might be suitable names for this option. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When control is accomplished by keyed command or option code entries, if a default is defined for a null control entry then indicate that default to the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here the phrase "null control entry" refers to pressing an ENTER key without first keying a command or option code (and without any accompanying data). It does not refer to defaults for optional parameters that might accompany a valid control entry, whose values might be displayed only at user request. It is not necessary that any defaults be defined for null control entries. In such cases, the computer might simply respond | ENTER alone is not recognized here. | The point here is that when defaults are defined, and when they vary from one transaction to another, then users should be informed of the current default logic. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If a consistent default is adopted throughout interface design, that default need not be explicitly indicated for each individual transaction. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| Press ENTER to see more options. |</span><span class="style1"> </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Offer users only control options that are actually available for the current transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If certain options are not yet implemented, as during system development, or are not available for any other reason, those should be annotated on the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/18 Menu Options Dependent on Context3.1.4/12 Disabling Unneeded Function Keys6.0/11 Disabling Unneeded Controls</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>635 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/10 Only Available Options Offered</span></text>
</content>
<name>3.2/10</name>
<script></script>
</card>
card_167711.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Employ task-oriented wording for control options to reflect the user's view of the current transaction. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When assigning aircraft to a mission, the relevant control option should be ASSIGN rather than ENTER. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When users must select options by code entry, display the code associated with each option in a consistent distinctive manner. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In many applications an equal sign can be used to designate option codes, such as </span><span class="style8">| N = Next page |, | P = Prev page |</span><span class="style1">, etc. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When users must select options by keyed entry of a corresponding code, place the cursor in the control entry area at display generation. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.7.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/16 Consistent Cursor Positioning</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>632 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/7 Cursor Placement for Keyed Entry of Options</span></text>
</content>
<name>3.2/7</name>
<script></script>
</card>
card_166966.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users will select among displayed options by pointing, place the cursor on the first (most likely) option at display generation. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with whatever information may be needed to guide control entries at any point in a transaction sequence, by incorporating prompts in a display and/or by providing prompts in response to requests for HELP. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.1.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/1 Guidance Information Always Available</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Make available to users a list of the control options that are specifically appropriate for any transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Transaction-specific options might be listed in the working display if there is space for them. Otherwise, they might be displayed in an overlay window at user request. Treat control options that are available for almost any transaction as implicit options, which need not be included in a list of transaction-specific options unless they are particularly appropriate to the current transaction. One convenient way to offer implicit options is via function keys, although some experienced users may prefer to select implicit options by command entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.4/2 Function Keys for Frequent Control Entries4.4/1 Guidance Information Always Available4.4/6 Transaction-Specific Option Display</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design the general options list to show control entry options grouped, labeled and ordered in terms of their logical function, frequency and criticality of use, following the general guidelines for menu design. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/2 General List of Control Options4.4/3 Logical Menu Structure3.1.3 Dialogue Type Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>628 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/3 Organization and Labeling of Listed Options</span></text>
</content>
<name>3.2/3</name>
<script></script>
</card>
card_165824.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a general list of basic control options that will always be available to serve as a "home base" or consistent starting point for control entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Return to this starting point can be accomplished by an OPTIONS function key, or by an explicit control option on every display, or by a generally available implicit option. Such a capability may be helpful even when all dialogue is user-initiated. It might be the general menu for a menu selection dialogue, or might be a standard starting point for composing command entries. However a user should not be required to return to a display of general options in order to make a control entry. If a user remembers option codes or commands, ideally those control entries could be made from any point in a transaction sequence. </span></text>
<text>3.1.3/26 General Menu3.1.5/12 General List of Commands4.4/2 General List of Control Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>627 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/2 General List of Control Options</span></text>
</content>
<name>3.2/2</name>
<script></script>
</card>
card_165576.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to select transactions; computer processing constraints should not dictate sequence control. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When a logical sequence of transactions can be determined in advance, interface design might encourage and help a user to follow that sequence. Guidance may be desirable though constraint is not. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user who wants to interrupt a current activity should not be required by the computer to complete some long sequence of useless transactions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.6.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/1 Flexible Sequence Control3.0/4 User Initiative in Sequence Control3.0/5 Control by Explicit User Action4.0/2 Explicit User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>626 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.2 Transaction Selection</span><span class="style21">3.2/1 User Control in Transaction Selection</span></text>
</content>
<name>3.2/1</name>
<script></script>
</card>
card_165285.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider graphic means for displaying to users prompting aids and other guidance pertaining to current control actions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A guidance display providing a graphic representation of keypad layout with notes explaining the various key functions might help a novice user to learn the control options available via function keys. A graphic representation of command syntax might aid language learning by novice users who could be confused by other forms of symbolic notation. A graphic representation of logical combinations specified in query formulation might help reduce errors in the use of query language. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Consider graphic means for displaying to users the context of current control actions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A graphic representation of the currently selected values of functions, elements and attributes affecting control actions might help reduce user errors in sequence control. Graphic techniques might be used to display the scope of a proposed control action, such as outlining a passage of text (or other group of display elements) currently selected for deletion. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For casual system users, consider providing a capability for direct manipulation of displayed objects as a means of sequence control. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In sequence control by direct manipulation, the techniques for selecting and moving displayed objects would be similar to those described in guidelines for graphic data entry. An extension of this idea is the use of "embedded menus" in which various items within a working display are highlighted in some way to indicate that they can be selected to obtain further information. Thus a text display of encyclopedia information might highlight certain words as cross references to related material, words which can be selected in context rather than from some separate menu listing. Advocates recommend direct manipulation as a means of enhancing a user's understanding of control actions, arguing that such manipulation can help clarify the relations among abstract objects and processes. Others recommend manipulation as a simple alternative to learning a command language, arguing that it is easier for a user to see and point than to remember and type. Critics argue that for experienced users direct manipulation will generally not be as efficient as other methods of sequence control. If direct manipulation is provided, some other more efficient alternative such as command language should also be available for those users who can learn it. Unfortunately, direct manipulation suffers the same drawback as that cited for iconic menus, namely, this mode of graphic interaction does not aid transition to the use of command language as novice users gain experience. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Rather than compose a command or select a function key to file a document, a user might move a displayed icon representing the document to superimpose it on another icon representing a file. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If icons are used to represent control actions in menus, display a verbal label with each icon to help assure that its intended meaning will be understood. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some of the objects and processes dealt with in sequence control are necessarily abstract, and so may be difficult to depict by iconic representation. A redundant verbal label might help make the meaning clear to a user who is uncertain just what a displayed icon means. One skeptic of iconic representation has cited the problems of early logographic languages, such as Egyptian hieroglyphs, and reminds us, "It took about 2500 years to get rid of the iconic shapes that we are now reviving for computer workstations." </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When system users have different linguistic backgrounds, consider providing graphic menus which display icons to represent the control options. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here "icon" is intended to mean a small graphic figure which represents a control operation or object. Some advocates recommend the use of icons whenever possible in place of verbal labels or explanations. They argue that icons can have universal meaning for users with different linguistic backgrounds. Whereas verbal labels may require translation into other languages for different user groups. Some critics, however, are concerned that the meaning of icons may not be clear. Careful testing may be required to develop a satisfactory set of icons in terms of both legibility and interpretability. And even then it may prove a wise precaution to supplement icons by displaying redundant verbal labels. One serious drawback of iconic menus is that they will not permit the sequential concatenation of coded menu selections that can ease the transition to command entry as novice users become more experienced. Thus iconic menus are more appropriate for casual rather than continuing use. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A computer-based information system at an international airport might display graphic menus with icons to indicate simple control options. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Barnard Marcel 1984Bewley etal 1983Foley Van Dam 1982Muter Mayson 1986Smith Irby Kimball Verplank 1982</text>
<text><span class="style10">Γêå Statement</span><span class="style1">For casual users, consider providing graphic aids to supplement other types of sequence control. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Advocates recommend simple graphic interaction techniques as an aid for casual users, so that they will not have to learn more complicated methods of sequence control such as command entry. It is that potential use of graphic interaction to simplify control dialogue that is discussed in this section of the guidelines. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>620 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.8 Dialogue Type - Graphic Interaction</span><span class="style21">3.1.8/2 Graphic Control Aids for Casual Users</span></text>
</content>
<name>3.1.8/2</name>
<script></script>
</card>
card_163678.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For users who must work with graphic data, provide control capabilities as recommended in guidelines for graphic data entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Methods of user interaction with graphic data may be so complex that they can be exploited fully only by skilled users. Design recommendations for that specialized kind of graphic interaction are discussed in guidelines pertaining to graphic data entry (Section 1.6). </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6 Graphics</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>619 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.8 Dialogue Type - Graphic Interaction</span><span class="style21">3.1.8/1 Control of Graphic Data</span></text>
</content>
<name>3.1.8/1</name>
<script></script>
</card>
card_163409.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider using some constrained form of natural language dialogue in applications where task requirements are broad ranging and poorly defined, and where little user training can be provided. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Computer processing of natural language is now being developed on an experimental basis. Current capabilities permit computer recognition of constrained forms of "natural" language, with some limits on vocabulary and syntax. Such constrained natural languages might be considered akin to command languages, with the drawback that they are probably not as carefully designed. For untrained users, the seemingly familiar form of a (constrained) natural language dialogue may help introduce them to computer capabilities. Such users may manage to do something right from scratch, without having to surmount an initial hurdle of learning more specialized command languages and control procedures. As users gain experience, they may eventually learn more efficient methods of interacting with the system. On the other hand, infrequent computer users may forget whatever training they receive, and so remain novices indefinitely. Do not consider using unconstrained natural language dialogues for current interface design. Even if a computer can be programmed to recognize unconstrained natural language, it is not clear whether that would help in any defined information handling task. A natural language will often cause confusion in communication among its human users. Something better may be needed to mediate human communication with computers. For applications where task requirements are well defined, other types of dialogue will probably prove more efficient. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a query will result in a large-scale data retrieval, require the user to confirm the transaction or else take further action to narrow the query before processing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In this regard, it may be helpful to permit a user to set some upper bound for data output, in effect to define what constitutes a "large-scale" retrieval. It may help a user to decide whether to confirm or modify a pending query, if the user can request a partial display of the currently specified data output. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design a query language to allow the logical linking of sequential queries. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Logical linking of queries might be accomplished with referential pronouns ("of them", "of those") that will be recognized by the computer in terms of current context. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design a query language to include logic elements that permit users to link sequential queries as a single entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">However a query language should be designed so that it does not require logical links. Some logical quantifiers ("greater than", "less than", etc.) may confuse users. As an alternative to logical linking, it may prove helpful to allow a user to formulate a series of simple queries to narrow the set of retrieved data. It may help a user to specify logical links accurately if the computer can display a graphical depiction of relations among data sets as those relations are specified during query composition. One researcher recommends Venn diagrams for this purpose. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Common links for query formulation include "and", "or", etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Michard 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.8/7 Graphic Display of Control Prompting</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>615 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.6 Dialogue Type - Query Language</span><span class="style21">3.1.6/7 Logic to Link Queries</span></text>
</content>
<name>3.1.6/7</name>
<script></script>
</card>
card_162338.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design a query language to minimize the need for quantifiers in query formulation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">People have difficulty in using quantifiers. If a query language does require quantifiers, it may be helpful to allow a user to select the desired quantifier from a set of sample queries worded to maximize their distinctiveness. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Negative quantifiers ("no", "none", "zero", etc.) are particularly difficult for users to deal with; other potentially confusing quantifiers include indefinite ("some", "any") and interrogative ("how many") forms. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>614 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.6 Dialogue Type - Query Language</span><span class="style21">3.1.6/6 Minimal Need for Quantifiers</span></text>
</content>
<name>3.1.6/6</name>
<script></script>
</card>
card_162100.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to employ alternative forms when composing queries, corresponding to common alternatives in natural language. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When quantifying a query, a user should be able to employ equivalent forms, such as "over 50," "more than 50," "51 or more." </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design a query language so that the wording of a query simply specifies what data are requested; a user should not have to tell the computer how to find the data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This objective has been called "nonprocedurality", meaning that a user should not have to understand computer procedures for finding data. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Establish one single representation of the data organization for use in query formulation, rather than multiple representations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Beginners or infrequent users may be confused by different representational models. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If different queries will access different data bases over different routes, a user should not necessarily need to know this. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Michard 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/18 Index of Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>611 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.6 Dialogue Type - Query Language</span><span class="style21">3.1.6/3 Coherent Representation of Data Organization</span></text>
</content>
<name>3.1.6/3</name>
<script></script>
</card>
card_161291.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design a query language so that it reflects a data structure or organization perceived by users to be natural. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The users' natural perception of data organization can be discovered by survey or experimentation. When users' perceptions do not match the actual structure of computer-stored data, then special care will be needed to preserve the users' viewpoint in query language design. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user supposes that all data about a particular person are stored in one place, then the query language should probably permit such data to be retrieved by a single query, even though actual computer storage might carry the various data in different files. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Durding Becker Gould 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>610 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.6 Dialogue Type - Query Language</span><span class="style21">3.1.6/2 Natural Organization of Data</span></text>
</content>
<name>3.1.6/2</name>
<script></script>
</card>
card_161125.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider query language dialogue for tasks emphasizing unpredictable information retrieval (as in many analysis and planning tasks), with moderately trained users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Guidelines for command language design would apply equally to query languages. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a command entry may have disruptive consequences, require the user to review and confirm a displayed interpretation of the command before it is executed. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/8 User Warned of Potential Data Loss6.0/18 User Confirmation of Destructive Actions</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a user makes a command entry error, after the error message has been displayed allow the user to enter a new command; a user should not be forced to correct and complete an erroneous command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In considering a command entry error message, a user may decide that the wrong command was chosen in the first place, and wish to substitute another command instead. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a command entry is not recognized, allow the user to revise the command rather than rejecting the command outright. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Misstated commands should not simply be rejected. Instead, software logic should guide users toward proper command formulation. Preserve the faulty command for reference and modification, and do not require a user to rekey the entire command just to change one part. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/2 Command Editing4.3/15 User Editing of Entry Errors</text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a system will have many novice or infrequent users, ensure that the computer can recognize probable alternative forms of command syntax. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">What alternative syntax should be recognized can be determined by analysis of user error records in prototype testing. Recognition of alternative syntax will require more complex parsing of commands, perhaps enlarging by several times that segment of interface software. But that effort will be justified by increased recognition of user entries. Infrequent users may need to relearn syntax rules each time they use the system. For those users, time spent learning syntax is not worthwhile considering that they will seldom use that syntax. Recognizing alternative syntax will be helpful for users who are experienced with different systems. For instance, if users of different editors must occasionally use the same mail system, that mail system might permit alternative syntax corresponding to the syntax of those different editors. If user experience with other systems is known, as when all users of a mail system use one of two editors, designers should provide for those different syntax forms. Otherwise, the users themselves might be permitted to tailor command syntax to employ familiar forms. If most system users will gain expertise through frequent use, then documentation and error messages should be provided to help new users learn accepted syntax, rather than permitting them to use alternative syntax forms. When a command language has been carefully designed to minimize keystrokes and errors, and ensure that similar commands require the same syntax, frequent users will benefit from time spent learning acceptable syntax rather than designing their own language. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The computer might accept alternative methods of specifying a document, such as "memo 3", "memo #3", "#3", or simply "3"; users might be allowed to use different punctuation and/or to list command modifiers in different orders. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Good Whiteside Wixon Jones 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>605 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/22 Recognizing Alternative Syntax</span></text>
</content>
<name>3.1.5/22</name>
<script></script>
</card>
card_159947.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a system will have many novice or infrequent users, ensure that the computer can recognize a variety of synonyms for each word defined in the command language. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">What synonyms are frequently employed can be determined by analysis of user error records in prototype testing. Infrequent users may need to relearn command names each time they use the system. For those users, time spent learning commands is not worthwhile considering that they will seldom use those commands. Command synonyms will be helpful for users who are experienced with different systems. For instance, if users of different editors must occasionally use the same mail system, that mail system might permit synonyms for such common functions as creating and storing documents. If user experience with other systems is known, as when all users of a mail system use one of two editors, designers should include appropriate synonyms. Otherwise, the users themselves might be permitted to tailor command names to employ familiar terminology. If most system users will gain expertise through frequent use, then documentation and error messages should be provided to help new users learn accepted commands, rather than permitting them to enter command synonyms. When a command language has been carefully designed, with easily distinguishable command names and rule-based abbreviations, frequent users will benefit from time spent learning that command language rather than designing their own language. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The words "mail", "post", and "transmit" might be accepted synonyms for the command "send". </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Where the set of potential command entries is well defined, program the computer to recognize and execute common misspellings of commands, rather than requiring re-entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice should permit a sizable reduction in wasted keying without serious risk of misinterpretation. The necessary software logic is akin to that for recognizing command abbreviations. For novice users, it may be helpful for the computer to display an inferred command for user confirmation before execution. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to edit erroneous commands with the same techniques that are employed to edit data entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent editing techniques will speed learning and reduce errors. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>602 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/19 Standard Techniques for Command Editing</span></text>
</content>
<name>3.1.5/19</name>
<script></script>
</card>
card_159073.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to abbreviate commands. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As a corollary, misspelled command entries should also be tolerated, within the limits of computer recognition. The computer can interrogate a user as necessary to resolve ambiguous entries. If a command language is still changing, as during system development, do not permit variable abbreviation. For the user, an abbreviation that works one day may not work the next. For the software designer, the addition of any new command might require revision of recognition logic for other commands. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a "P" uniquely identifies a print command (i.e., no other commands start with "P") then a user should be able to enter PRINT, or PR, or P, or any other truncation to initiate printing. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.4.3Demers 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>601 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/18 Abbreviation of Commands</span></text>
</content>
<name>3.1.5/18</name>
<script></script>
</card>
card_158945.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Treat single and multiple blanks between words as equivalent when processing command entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">People cannot readily distinguish one blank space from several, and so the computer should not impose such a distinction. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/30 Single and Multiple Blanks Equivalent</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>600 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/17 Ignoring Blanks in Command Entry</span></text>
</content>
<name>3.1.5/17</name>
<script></script>
</card>
card_158529.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If command punctuation other than spaces is required, perhaps as a delimiter to distinguish optional parameters or to separate entries in a stacked command, adopt a single standard delimiter symbol for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Whatever symbol is adopted as a delimiter for command entries should preferably be the same as any delimiter that might be used when making data entries. Note, however, that even if some single delimiter is specified for consistent use in command punctuation, command entry will be slower and less accurate than if no delimiter at all were required. People do not punctuate reliably. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A slash (/) might be a good choice. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/4 Standard Delimiter Character3.2/17 Standard Delimiter in Entry Stacking</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>599 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/16 Standard Delimiter</span></text>
</content>
<name>3.1.5/16</name>
<script></script>
</card>
card_158281.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to enter commands without any punctuation other than the spaces between words. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Command entry will be faster and more accurate when spaces are used rather than any other kind of punctuation. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to assign a single name to a defined series of commands and then use that named "macro" for subsequent command entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In this way users can make a frequent but complicated task easier to accomplish, when the interface designer has failed to anticipate that particular need. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Demers 1981Foley Wallace 1974</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.2/18 User Definition of Macro Commands</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>597 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/14 User Definition of Macro Commands</span></text>
</content>
<name>3.1.5/14</name>
<script></script>
</card>
card_157830.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to key a series of commands at one time ("command stacking"). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will allow experienced users to by-pass prompting sequences. Command stacking will reduce the extended memory load on users. Command stacking may also be much faster than separate entry of commands, in systems where input/output processing is overloaded by multiple users. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.9</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.2/13 Stacked Control Entries4.4/12 User-Requested Prompts</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a general list of basic commands, with appropriate command format guidance, that will always be available to serve as a "home base" or consistent starting point for composing command entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such a general list of commands might provide more comprehensive user guidance than is possible when prompting command entry from a working display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.2/2 General List of Control Options4.4/2 General List of Control Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>595 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/12 General List of Commands</span></text>
</content>
<name>3.1.5/12</name>
<script></script>
</card>
card_157390.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to request computer-generated prompts as necessary to determine required parameters in a command entry, or to determine available options for an appropriate next command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications it may be desirable to let an inexperienced user simply choose a general "prompted mode" of operation, where any command entry produces automatic prompting of (required or optional) parameters and/or succeeding entry options. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Using a HELP function key, or perhaps simply keying a question mark in the command entry area, would be satisfactory methods to request prompting. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design a command language with flexibility to permit a user to assign personal names to files, frequently used commands, etc. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Frequently used commands should be easy for a user to enter. Where users differ in the frequency of the commands they use, perhaps the designer should provide for flexibility in command naming. On the other hand, users will not be perfectly consistent in specifying command names, and a carefully designed set of commands might well prove better for some applications. For users who must move back and forth between different systems with differently defined command languages, some flexibility in command naming might permit those users to establish their own consistent terminology. Before users can be allowed to adopt their own assigned command names, the computer must check those names to prevent duplication. A potential risk of increased flexibility is increased confusion, if users forget what names they have specified for commands and data files. The computer should maintain a current index of command and file names for on-line user reference. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Carroll 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.2/18 User Definition of Macro Commands4.4/18 Index of Data4.4/19 Index of Commands</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design words and abbreviations in a command language with distinctive spelling, so that simple spelling errors will be recognized as such rather than invoking a different command. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When a system has only a few commands, all of those commands should be distinctive. When a system has many commands, it may not be possible to ensure that each is distinctive. In that case, it is important to ensure that any commands which are destructive or time-consuming are made distinctive. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, if one command name is DELETE, abbreviated DEL, then another command should not be named DELIVER, with an abbreviation of DELR. Instead, ERASE could be substituted for DELETE, or SEND for DELIVER. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.2.5</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>592 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/9 Distinctive Spelling for Commands</span></text>
</content>
<name>3.1.5/9</name>
<script></script>
</card>
card_156647.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design words in a command language so that they are distinctive from one another, and emphasize significant differences in function. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In general, do not give different commands semantically similar names, such as SUM and COUNT, or ERASE and DELETE, or QUIT and EXIT. System design abounds with negative examples of similarly named commands which confuse their users: DISPLAY and VIEW (where one command permits editing displayed material and one does not), COMPOSE and CREATE (where one command sends a composed message to an outbox and one leaves a message on the desk), etc. Even experienced users will make errors with such commands. Some researchers deal with this question by recommending the use of specific rather than general command names. </span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/8 Distinctive Meaning for Commands</span></text>
</content>
<name>3.1.5/8</name>
<script></script>
</card>
card_156360.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design all words in a command language, and their abbreviations, to be consistent in meaning from one transaction to another, and from one task to another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, do not use EDIT in one place, MODIFY in another, UPDATE in a third, all referring to the same kind of action. Choose wording so that commands will be congruent with one another, following natural language patterns; if one command is UP, its complement should be DOWN; other natural complements include RIGHT-LEFT, FORWARD-BACK, IN-OUT, PUSH-PULL, RAISE-LOWER, etc. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Choose words for a command language that reflect the user's point of view, and correspond to the user's operational language. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">To transfer a file, the assigned command should be something like TRANSFER, MOVE, or SEND, and not some jargon term like PIP. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.1.1 4.2.12 4.2.13MIL-STD-1472C 1983 § 5.15.4.5.2</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Choose command names that are meaningful, and that specifically describe the functions being implemented. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some systems, functions are arbitrarily assigned letters as command names, e.g., the letter D preceded by a special key such as CONTROL might be a LOG-OFF command. In such cases, when command names are not real words that describe system functions, users will have difficulty learning to use the system. If users are permitted to enter abbreviations rather than complete command names, ensure that users are told the command name represented by the abbreviation. Otherwise, a short abbreviation may seem an arbitrary code. For instance, a prompt might read </span><span class="style8">| To DELETE a record, enter D | </span><span class="style1">rather than </span><span class="style8">| To erase a record, enter D | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design a command language so that its functions are organized in groups (or "layers") for ease in learning and use. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The fundamental layer of the language should be the easiest, allowing use of the system by people with little training and/or limited needs. Successive layers of the command language can then increase in complexity for users with greater skills. In effect, simple versions of commands can be recognized by defaulting all of the optional parameters. Control forms might be used to display default options for complicated commands. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user should be able to display the next of a set of received messages with some simple command such as READ NEXT, although a complete command to retrieve any message might include potential specification of which message, from which message list, in which format, to which output device. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Reisner 1977</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.2/3 Defaults for Control Entry4.4/31 Flexible Training</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design a command language so that a user can enter commands in terms of functions desired, without concern for internal computer data processing, storage and retrieval mechanisms. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Where file names are not unique identifiers, the computer should be programmed to determine whatever further context is necessary for identification. Or perhaps the computer should ask the user to designate a "directory" defining the subset of files of current interest. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Users should be able to request display of a data file by name alone, without any further specification such as that file's location in computer storage. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When command language is used for sequence control, provide a command entry area in a consistent location on every display, preferably at the bottom. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Adjacent to the command entry area there should be a display window reserved for prompting entries, for recapitulation of command sequences (with scrolling to permit extended review), and to mediate question-and-answer dialogue sequences (i.e., prompts and responses to prompts). </span></text>
<text>2.5/11 Command Entry, Prompts, Messages at Bottom3.1.3/8 Standard Area for Code Entry4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>585 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.5 Dialogue Type - Command Language</span><span class="style21">3.1.5/2 Standard Display Area for Command Entry</span></text>
</content>
<name>3.1.5/2</name>
<script></script>
</card>
card_154689.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider command-language dialogues for tasks involving a wide range of control entries, where users may be highly trained and will use the system frequently. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Command language should also be considered for tasks where control entries may be mixed with data entries in arbitrary sequence, such as when making flight reservations. Such applications will generally require extensive user training. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">The layout of function keys should be compatible with their importance; give keys for emergency functions a prominent position and distinctive coding (e.g., size and/or color); provide physical protection for keys with potentially disruptive consequences. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.0/12 Protecting Physical Controls</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>583 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/18 Layout Compatible with Use</span></text>
</content>
<name>3.1.4/18</name>
<script></script>
</card>
card_154235.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Group function keys in distinctive locations on the keyboard to facilitate their learning and use; place frequently used function keys in the most convenient locations. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.3.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/8 Distinctive Format for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>582 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/17 Distinctive Location</span></text>
</content>
<name>3.1.4/17</name>
<script></script>
</card>
card_154009.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If the functions assigned to a set of keys change as a result of user selection, give the user an easy means to return to the initial, base-level functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In effect, multifunction keys can provide hierarchic levels of options much like menu selection dialogues, with the same need for rapid return to the highest-level menu. For some applications, it may be desirable to automate the return to base-level assignment of multifunction keys, to occur immediately on completion of a transaction and/or by time-out following a period of user inaction. The optimum period for any automatic time-out would have to be determined empirically for each application. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In cockpit design, where multifunction keys may be used for various purposes such as navigation or weapons control, the pilot should be able to take a single action to restore those keys quickly to their basic flight control functions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Aretz Kopala 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>581 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/16 Easy Return to Base-Level Functions</span></text>
</content>
<name>3.1.4/16</name>
<script></script>
</card>
card_153709.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a function key performs different functions in different operational modes, assign equivalent or similar functions to the same key. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A particular key might be used to confirm data changes in one mode, confirm message transmission in another, etc. As a negative example, a key labeled RESET should not be used to save data in one mode, dump data in another, and signal task completion in a third (cited from an actual design). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Stewart 1980</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>580 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/15 Consistent Functions in Different Operational Modes</span></text>
</content>
<name>3.1.4/15</name>
<script></script>
</card>
card_153494.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a function is assigned to a particular key in one transaction, assign that function to the same key in other transactions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This becomes a design issue, of course, only in applications where the set of needed functions does vary somewhat from one transaction to another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A SAVE key should perform the same function at any point in a transaction sequence. </span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/14 Consistent Assignment of Function Keys</span></text>
</content>
<name>3.1.4/14</name>
<script></script>
</card>
card_153145.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a function is continuously available, assign that function to a single key. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.3.4</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>578 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/13 Single Key for Continuous Functions</span></text>
</content>
<name>3.1.4/13</name>
<script></script>
</card>
card_153046.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When function keys are not needed for any current transaction, temporarily disable those keys under computer control; do not require users to apply mechanical overlays for this purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a user selects a function key that is invalid for the current transaction, no action should result except display of an advisory message indicating what functions are available at that point. </span></text>
<text>3.2/10 Only Available Options Offered3.5/1 Appropriate Response to All Entries6.0/11 Disabling Unneeded Controls</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>577 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/12 Disabling Unneeded Function Keys</span></text>
</content>
<name>3.1.4/12</name>
<script></script>
</card>
card_152702.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If some function keys are active and some are not, indicate the current subset of active keys in some noticeable way, perhaps by brighter illumination. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will speed user selection of function keys. </span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/11 Indicating Active Function Keys</span></text>
</content>
<name>3.1.4/11</name>
<script></script>
</card>
card_152490.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When function key activation does not result in any immediately observable natural response, provide users with some other form of computer acknowledgment. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Temporary illumination of the function key will suffice, if key illumination is not used for other purposes such as indicating available options. Otherwise an advisory message should be displayed. As an interesting variation, user guidance prior to key activation might be provided, where partial depression of a double-contact function key would explain its use, either by voice output ("talking keyboard") or by visual display of a HELP message. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.3.8Geiser Schumacher Berger 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/14 Feedback for Control Entries4.2/1 Consistent Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>575 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/10 Feedback for Function Key Activation</span></text>
</content>
<name>3.1.4/10</name>
<script></script>
</card>
card_152172.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that any key will perform its labeled function with a single activation, and will not change its function with repeated activation. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">On a very compact keypad, where separate keys are not available to accommodate the range of needed functions, it might be acceptable to group logically related functions on a single key, where repeated key activation would extend the range of control action in a consistent way, e.g., to DELETE character, word, sentence, or paragraph with repeated keystrokes. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.3.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/2 Explicit User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>574 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/9 Single Activation of Function Keys</span></text>
</content>
<name>3.1.4/9</name>
<script></script>
</card>
card_151926.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If double (control/shift) keying is used, the logical relation between shifted and unshifted functions should be consistent from one key to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistency in the underlying logic for double keying will help a user to learn the functions associated with different keys. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">One consistent logic might be that shifted and unshifted functions are opposite, so that if a particular key moves the cursor forward then that key when shifted would move the cursor backward. Another possible logic might be that shifted and unshifted functions are related by degree, so that if a particular key deletes a single displayed character then that key when shifted would delete a word. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>573 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/8 Consistent Logic for Double Keying</span></text>
</content>
<name>3.1.4/8</name>
<script></script>
</card>
card_151747.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If double (control/shift) keying is used, the functions paired on one key should be logically related. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a particular function key moves the cursor to the upper left corner of a display screen, then that same key when shifted might be used to move the cursor to the bottom right corner of the screen. As a negative example, a function key that moves the cursor should not be used when shifted to delete displayed data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Stewart 1980</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>572 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/7 Logical Pairing of Double-Keyed Functions</span></text>
</content>
<name>3.1.4/7</name>
<script></script>
</card>
card_151406.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Keys controlling frequently used functions should permit single key action and should not require double (control/shift) keying. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>571 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/6 Single Keying for Frequent Functions</span></text>
</content>
<name>3.1.4/6</name>
<script></script>
</card>
card_151044.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a key is used for more than one function, always indicate to the user which function is currently available. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a key is used for just two functions, depending upon defined operational mode, then alternate illuminated labels might be provided on the key to indicate which function is current. In those circumstances, it is preferable that only the currently available function is visible, so that the labels on a group of keys will show what can be done at any point. If key function is specific to a particular transaction, provide an appropriate guidance message on the user's display to indicate the current function. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Label each function key informatively to designate the function it performs; make labels sufficiently different from one another to prevent user confusion. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example of uninformative labeling, cited from an actual design, logging onto a system should not be initiated by a key labeled PANIC. As a negative example of confusingly similar labeling, two keys should not be labeled ON and DN. </span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/4 Distinctive Labeling of Function Keys</span></text>
</content>
<name>3.1.4/4</name>
<script></script>
</card>
card_150640.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider function keys for interim control entries, i.e., for control actions taken before the completion of a transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Interim control refers to an action taken by a user while working with displayed data, e.g., while still keying data entries or changes, etc. Function keys will aid interim control entries partly because those entries may be frequent. More importantly, however, function keys permit those control entries to be made without special cursor positioning, so that they do not interfere with data entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Function keys will aid such interim actions as DITTO, CONFIRM, and requests for PRINT, or HELP, and also interrupts such as BACKUP, CANCEL, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>568 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/3 Function Keys for Interim Control Entries</span></text>
</content>
<name>3.1.4/3</name>
<script></script>
</card>
card_150350.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider function keys for frequently required control entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When frequently used options are always available via function keys, they need not be included in displayed menus. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Commonly used function keys include ENTER, PRINT, NEXT PAGE, PREV PAGE, OPTIONS, etc. </span></text>
<text>3.1.3/28 Easy Selection of Important Options3.2 Transaction Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>567 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/2 Function Keys for Frequent Control Entries</span></text>
</content>
<name>3.1.4/2</name>
<script></script>
</card>
card_150107.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider function keys for tasks requiring only a limited number of control entries, or for use in conjunction with other dialogue types as a ready means of accomplishing critical entries that must be made quickly without syntax error. </span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.4 Dialogue Type - Function Keys</span><span class="style21">3.1.4/1 Function Keys for Critical Control Entries</span></text>
</content>
<name>3.1.4/1</name>
<script></script>
</card>
card_149947.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For menu selection by code entry, when a series of selections can be anticipated before the menus are displayed, permit a user to combine those selections into a single "stacked" entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If necessary, stacked sequential entries might be separated by some character, such as a space, slash, comma or semicolon. It would be preferable, however, if they were simply strung together without special punctuation. Computer interpretation of an unpunctuated string will require letter codes (by preference) or fixed-digit number codes for option selection. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.9Badre 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.3/13 Letter Codes for Menu Selection3.2/13 Stacked Control Entries3.2/14 Consistent Order in Entry Stacking3.2/15 Abbreviation in Entry Stacking3.2/16 Minimal Punctuation of Stacked Entries3.2/17 Standard Delimiter in Entry Stacking3.5/4 Errors in Stacked Commands3.5/5 Partial Execution of Stacked Commands</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>565 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/36 Stacking Menu Selections</span></text>
</content>
<name>3.1.3/36</name>
<script></script>
</card>
card_149689.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow experienced users to by-pass a series of menu selections and make an equivalent command entry directly. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In effect, a command entry might specify an option anywhere in a hierarchic menu structure, permitting a user to jump down several levels, or to move directly from one branch to another. If a command by-passes only a portion of the complete menu sequence, and so does not yet specify a complete control entry, then display the appropriate next menu to guide completion of the control entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text>3.0/2 Minimal User Actions3.1.3/1 Menu Selection3.1.3/12 Option Wording Consistent with Command Language4.4/31 Flexible Training</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>564 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/35 By-Passing Menu Selection with Command Entry</span></text>
</content>
<name>3.1.3/35</name>
<script></script>
</card>
card_149390.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When hierarchic menus are used, require users to take only one simple key action to return to the general menu at the top level. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This action could be considered analogous to the REVIEW option proposed as an interrupt for sequence control. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.3/26 General Menu3.3/5 REVIEW Option</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>563 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/34 Return to General Menu</span></text>
</content>
<name>3.1.3/34</name>
<script></script>
</card>
card_149127.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When hierarchic menus are used, require users to take only one simple key action to return to the next higher level. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This action could be considered analogous to the BACKUP option proposed as an interrupt for sequence control. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.4.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.3/4 BACKUP Option</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>562 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/33 Return to Higher-Level Menus</span></text>
</content>
<name>3.1.3/33</name>
<script></script>
</card>
card_148746.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When hierarchic menus are used, ensure that display format and selection logic are consistent at every level. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.1.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>561 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/32 Consistent Design of Hierarchic Menus</span></text>
</content>
<name>3.1.3/32</name>
<script></script>
</card>
card_148684.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Format the display of hierarchic menus so that options which actually accomplish control entries can be distinguished from options which merely branch to other menu frames. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications, it may prove efficient to design "hybrid" menus which display one branch of the menu hierarchy elaborated to include all of its control options while other branches are simply indicated by summary labels. In such a hybrid menu, it will help orient users if options that accomplish control actions are highlighted in some way to distinguish them from options which will result in display of other frames of the hierarchic menu.</span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>560 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/31 Control Options Distinct from Menu Branching</span></text>
</content>
<name>3.1.3/31</name>
<script></script>
</card>
card_148412.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When hierarchic menus are used, display to the user some indication of current position in the menu structure. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">One possible approach would be to recapitulate prior (higher) menu selections on the display. If routine display of path information seems to clutter menu formats, then a map of the menu structure might be provided at user request as a HELP display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text>3.1.3/1 Menu Selection4.4/4 Hierarchic Menus</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>559 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/30 Indicating Current Position in Menu Structure</span></text>
</content>
<name>3.1.3/30</name>
<script></script>
</card>
card_148083.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">On separate menu displays (i.e., for menus not included with data displays), when menu selection is by pointing the computer should place the cursor automatically at the first listed option; when menu selection is by code entry, place the cursor in the command entry area. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When menu selection is by code entry, for some applications it may increase the efficiency of sequence control if a null entry is recognized as a default to the first displayed option (assuming that the first option is the most likely choice). If that is done, it should be done consistently. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/28 Automatic Cursor Placement3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>558 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/29 Automatic Cursor Placement</span></text>
</content>
<name>3.1.3/29</name>
<script></script>
</card>
card_147878.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When hierarchic menus are used, design their structure to permit immediate user access to critical or frequently selected options. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It may be desirable in general purpose systems whose use is varied and unpredictable, to permit users to tailor menu design (particularly the general menu) to their individual needs, so that the options used most frequently will appear first for each user. In designing fixed hierarchic menus, if frequent or critical options do appear logically at lower levels, and so will be less accessible, some design alternatives should be considered. For a critical action, some sort of "panic" option might be included in every menu display, or might be implemented by function key. For frequent actions, some special menu display might be provided as a supplementary shortcut to the designed menu hierarchy. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.2.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.4/2 Function Keys for Frequent Control Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>557 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/28 Easy Selection of Important Options</span></text>
</content>
<name>3.1.3/28</name>
<script></script>
</card>
card_147697.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users must step through a sequence of menus to make a selection, design the hierarchic menu structure to minimize the number of steps required. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This represents a trade-off against the need for logical grouping in hierarchic menus. Minimize the number of hierarchic levels, but not at the expense of display crowding. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/27 Minimal Steps in Sequential Menu Selection</span></text>
</content>
<name>3.1.3/27</name>
<script></script>
</card>
card_147215.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide a general menu of basic options as the top level in a hierarchic menu structure, a "home base" to which a user can always return as a consistent starting point for control entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Return to the general menu might be accomplished by an OPTIONS function key, or by an explicitly labeled option on every display, or by a generally available implicit option. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.3/34 Return to General Menu3.2/2 General List of Control Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>555 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/26 General Menu</span></text>
</content>
<name>3.1.3/26</name>
<script></script>
</card>
card_147109.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When menu selection must be made from a long list, and not all options can be displayed at once, provide a hierarchic sequence of menu selections rather than one long multipage menu. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Beginning users may learn faster and understand better a menu permitting a single choice from all available options, when those can be displayed on one page. However, a single long menu that extends for more than one page will hinder learning and use. The interface designer can usually devise some means of logical segmentation to permit several sequential selections among few alternatives instead of a single difficult selection among many. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Where a long list is already structured for other purposes, such as a list of customers, a parts inventory, a file directory, etc., it might be reasonable to require the user to scan multiple display pages to find a particular item. Even in such cases, however, an imposed structure for sequential access may prove more efficient, as when a user can make preliminary letter choices to access a long alphabetic list. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If menu options are grouped in logical subunits, give each group a descriptive label that is distinctive in format from the option labels themselves. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Although this practice might sometimes seem to waste display space, it will help provide user guidance. Moreover, careful selection of group labels may serve to reduce the number of words needed for individual option labels. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.1.10</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection4.4/4 Hierarchic Menus</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>553 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/24 Labeling Grouped Options</span></text>
</content>
<name>3.1.3/24</name>
<script></script>
</card>
card_146456.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If menu options are grouped in logical subunits, display those groups in a logical order; if no logical structure is apparent, then display the groups in the order of their expected frequency of use. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.6.6</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>552 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/23 Logical Ordering of Grouped Options</span></text>
</content>
<name>3.1.3/23</name>
<script></script>
</card>
card_146250.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Format a menu to indicate logically related groups of options, rather than as an undifferentiated string of alternatives. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Logical grouping of menu options will help users learn system capabilities. When logical grouping requires a trade-off against expected frequency of use, interface designers should resolve that trade-off consistently for those functions throughout the menu structure. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In vertical listing of options, subordinate categories might be indented. See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.2.8 2.3Foley Wallace 1974Liebelt McDonald Stone Karat 1982McDonald Stone Liebelt 1983</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection4.4/3 Logical Menu Structure</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>551 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/22 Logical Grouping of Menu Options</span></text>
</content>
<name>3.1.3/22</name>
<script></script>
</card>
card_145989.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">List displayed menu options in a logical order; if no logical structure is apparent, then display the options in order of their expected frequency of use, with the most frequent listed first. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| i = Initiate track | | m = Move track | | d = Delete track | </span><span class="style1">(Bad) </span><span class="style8">| d = Delete track | | i = Initiate track | | m = Move track | </span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text>2.3/2 Logical Organization2.5/17 Data Grouped by Frequency3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>550 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/21 Logical Ordering of Menu Options</span></text>
</content>
<name>3.1.3/21</name>
<script></script>
</card>
card_145852.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If menu options are included in a display that is intended also for data review and/or data entry, which is often a practical design approach, ensure that they are distinct from other displayed information; locate menu options consistently in the display and incorporate some consistent distinguishing feature to indicate their special function. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An interesting variation in menu design is the use of "embedded menus" in which various items within a working display are highlighted in some way to indicate that they can be selected to obtain further information. Thus a text display of encyclopedia information might highlight certain words as cross references to related material, words which can be selected in context rather than from some separate menu listing. Here the selectable items are made visually distinct without being segregated spatially. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">All control options might be displayed beginning with a special symbol, such as a plus sign </span><span class="style8">| +NEXT |, | +BACK |</span><span class="style1">, etc. See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Koved Shneiderman 1986</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/8 Distinctive Labeling3.1.3/1 Menu Selection3.1.8/5 Direct Manipulation4.0/8 Distinctive Format for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>549 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/20 Menus Distinct from Other Displayed Information</span></text>
</content>
<name>3.1.3/20</name>
<script></script>
</card>
card_145554.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When menus are provided in different displays, design them so that option lists are consistent in wording and ordering. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, if </span><span class="style8">| +PRINT |</span><span class="style1"> is the last option in one menu, the same print option should not be worded </span><span class="style8">| +COPY |</span><span class="style1"> at the beginning of another menu. See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.2.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.3/14 Consistent Coding of Menu Options4.0/15 Consistent Wording</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>548 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/19 Consistent Display of Menu Options</span></text>
</content>
<name>3.1.3/19</name>
<script></script>
</card>
card_145176.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design a menu to display only those options that are actually available in the current context for a particular user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a user selects a displayed option, and is then told that option is not actually available, an undesirable element of unpredictability has been introduced into the interface design. Users may become uncertain and confused about sequence control. Also irritated. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Menu displays for a system under development might display future options not yet implemented, but such options should be specially marked in some way so that users will understand that they are not available. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Privileged users might be shown more options than regular users. Displayed file directories should contain only those files actually available to the particular user. Offer a CHANGE option only to users who are authorized to make changes to the particular data being displayed. See sample displays in section 3.1.3/1.</span></text>
<text>3.1.3/1 Menu Selection3.2/10 Only Available Options Offered4.4/1 Guidance Information Always Available</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>547 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/18 Menu Options Dependent on Context</span></text>
</content>
<name>3.1.3/18</name>
<script></script>
</card>
card_145135.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design a menu to display all options appropriate to any particular transaction. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">A familiar set of general control options (i.e., options that are always implicitly available) may be omitted from individual displays; such general options might be selected by requesting a general menu, or perhaps by function key or command entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection4.4/1 Guidance Information Always Available3.2 Transaction Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>546 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/17 Complete Display of Menu Options</span></text>
</content>
<name>3.1.3/17</name>
<script></script>
</card>
card_144886.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When control entries for any particular transaction will be selected from a small set of options, show those options in a menu added to the working display, rather than requiring a user to remember them or to access a separate menu display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A complete display of control options will sometimes leave little room for display of data. If an extensive menu must be added to a working data display, provide that menu as a separate window that can temporarily overlay displayed data at user request, but can then be omitted again by further user action. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.1.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection4.4/5 Guidance for Sequence Control2.7.5 Display Control Window Overlays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>545 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/16 Explicit Option Display</span></text>
</content>
<name>3.1.3/16</name>
<script></script>
</card>
card_144473.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose a standard symbol for indicating that an entry is required, and reserve that symbol only for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some standard prompting symbol, such as the colon shown in the example here, will help to cue users that an input is required. The same symbol should be used to prompt data entries, code entries for menu selections, command entries, etc. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| ENTER organization type: | </span><span class="style1">(Bad) </span><span class="style8">| ENTER organization type | </span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.5.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/9 Standard Symbol for Prompting Entry3.1.3/1 Menu Selection4.4/10 Standard Symbol for Prompting Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>544 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/15 Standard Symbol for Prompting Entry</span></text>
</content>
<name>3.1.3/15</name>
<script></script>
</card>
card_144210.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If letter codes are used for menu selection, use those letters consistently in designating options from one transaction to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Different codes for the same action will tend to confuse users and impede learning. The same code for different actions will tend to induce user errors, especially if those actions are frequently taken. However, this practice may be tolerable when selections are seldom taken, and then always taken from labeled alternatives. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, the same action should not be given different names (and hence different codes) at different places in a transaction sequence, such as (Bad) </span><span class="style8">| f = Forward | </span><span class="style1">and </span><span class="style8">| n = Next | </span><span class="style1">As a negative example, the same code should not be given to different actions (Bad) </span><span class="style8">| q = Quit | </span><span class="style1">and </span><span class="style8">| q = Queue | </span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.3/19 Consistent Display of Menu Options4.0/15 Consistent Wording</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>543 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/14 Consistent Coding of Menu Options</span></text>
</content>
<name>3.1.3/14</name>
<script></script>
</card>
card_144032.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If menu selections are made by keyed codes, design each code to be the initial letter or letters of the displayed option label, rather than assigning arbitrary letter or number codes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Several significant advantages can be cited for mnemonic letter codes. Letters are easier than numbers for touch-typists to key. It is easier to memorize meaningful names than numbers, and thus letter codes can facilitate a potential transition from menu selection to command language when those two dialogue types are used together. When menus have to be redesigned, which sometimes happens, lettered options can be reordered without changing codes, whereas numbered options might have to be changed and so confuse users who have already learned the previous numbering. Interface designers should not create unnatural option labels just to ensure that the initial letter of each will be different. There must be some natural differences among option names, and special two- or three-letter codes can probably be devised as needed to emphasize those differences. In this regard, there is probably no harm in mixing single-letter codes with special multiletter codes in one menu. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Options might be numbered when a logical order or sequence is implied. When menu selection is from a long list, the line numbers in the list might be an acceptable alternative to letter codes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| m = Male | | f = Female | </span><span class="style1">(Bad) </span><span class="style8">| 1 = Male | | 2 = Female | </span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text>3.1.3/1 Menu Selection4.0/13 Consistent Coding Conventions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>542 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/13 Letter Codes for Menu Selection</span></text>
</content>
<name>3.1.3/13</name>
<script></script>
</card>
card_143634.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If menu selection is used in conjunction with or as an alternative to command language, design the wording and syntactic organization of displayed menu options to correspond consistently to defined elements and structure of the command language. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Where appropriate, display cumulative sequences of menu selections in a command entry area until the user signals entry of a completely composed command. This practice will speed the transition for a novice user, relying initially on sequential menu selection, to become an experienced user composing coherent commands without such aid. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">The wording of menu options should consistently represent commands to the computer, rather than questions to the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Wording options as commands will permit logical selection by pointing, will facilitate the design of mnemonic codes for keyed entry, and will help users learn commands in systems where commands can be used to by-pass menus. Wording options as commands implies properly that the initiative in sequence control lies with the user. Wording options as questions implies initiative by the computer. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For option selection by pointing, a "+" (or some other special symbol) might be used consistently to distinguish a selectable control option from other displayed items, as (Good)</span><span class="style8">| +PRINT | </span><span class="style1">(Bad) </span><span class="style8">| PRINT? | </span><span class="style1">For option selection by code entry, the code for each option should be consistently indicated, as (Good) </span><span class="style8">| p = Print |</span><span class="style1"> (Bad) </span><span class="style8">| Print? (Y/N) | </span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.6.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection3.1.3/20 Menus Distinct from Other Displayed Information4.0/23 Consistent Grammatical Structure</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>540 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/11 Menu Options Worded as Commands</span></text>
</content>
<name>3.1.3/11</name>
<script></script>
</card>
card_143119.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display an explanatory title for each menu, reflecting the nature of the choice to be made. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) (Bad) </span><span class="style8">| Organizational Role | | Select: | | r = Responsible | | r = Responsible | | a = Assigned | | a = Assigned | | p = Performing | | p = Performing | </span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.9.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>539 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/10 Explanatory Title for Menu</span></text>
</content>
<name>3.1.3/10</name>
<script></script>
</card>
card_143050.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user has selected and entered a control option from a menu, if there is no immediately observable natural response then the computer should display some other acknowledgment of that entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An explicit message might be provided. In some applications, however, it may suffice simply to highlight the selected option label (e.g., by brightening or inverse video) when that would provide an unambiguous acknowledgment. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.1.12</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/5 Fast Acknowledgement of Entry3.0/14 Feedback for Control Entries3.1.3/1 Menu Selection4.2/1 Consistent Feedback4.2/10 Indicating Item Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>538 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/9 Feedback for Menu Selection</span></text>
</content>
<name>3.1.3/9</name>
<script></script>
</card>
card_142813.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When menu selection is accomplished by code entry, provide a standard command entry area (window) where users enter the selected code; place that entry area in a fixed location on all displays. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In a customary terminal configuration, where the display is located above the keyboard, command entry should be at the bottom of the display, in order to minimize user head/eye movement between the display and the keyboard. Experienced users might key coded menu selections in a standard area identified only by its consistent location and use. If the system is designed primarily for novice users, however, that entry area should be given an appropriate label, such as </span><span class="style8">| ENTER choice here: ___. | </span><span class="style1"></span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text>3.1.3/1 Menu Selection3.1.5/2 Standard Display Area for Command Entry4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>537 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/8 Standard Area for Code Entry</span></text>
</content>
<name>3.1.3/8</name>
<script></script>
</card>
card_142509.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When menu selection is a secondary (occasional) means of control entry, and/or only short option lists are needed, then consider accomplishing selection by keyed entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An option might be selected by keying an associated code which is included in the displayed menu listing. Alternatively, if menu labels can be displayed near a screen margin, then an option might be selected by pressing an adjacent multifunction key. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>536 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/7 Menu Selection by Keyed Entry</span></text>
</content>
<name>3.1.3/7</name>
<script></script>
</card>
card_142317.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If menu selection is accomplished by pointing, provide for dual activation, in which the first action designates (positions a cursor at) the selected option, followed by a separate second action that makes an explicit control entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The two actions of cursor placement and entering should be compatible in their design implementation. If the cursor is positioned by keying, then an ENTER key should be used to signal control entry. If the cursor is positioned by lightpen, provide a dual-action "trigger" on the lightpen for cursor positioning and control entry. This recommendation for dual activation of pointing assumes that accuracy in selection of control entries is more important than speed. In some applications that may not be true. Interface design will involve a trade-off considering the criticality of wrong entries, ease of recovery from wrong entries, and user convenience in making selections. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">On a touch display, the computer might display a separate ENTER box that can be touched by a user to indicate that the cursor has been properly positioned. See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace 1974</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action1.1/4 Explicit Activation3.0/5 Control by Explicit User Action3.1.3/1 Menu Selection6.0/9 Control by Explicit User Action</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>535 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/6 Dual Activation for Pointing</span></text>
</content>
<name>3.1.3/6</name>
<script></script>
</card>
card_141832.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If menu selection is accomplished by pointing, as on touch displays, design the acceptable area for pointing to be as large as consistently possible, including at least the area of the displayed option label plus a half-character distance around that label. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The larger the effective target area, the easier the pointing action will be, and the less risk of error in selecting a wrong option by mistake. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.12Engel Granda 1975 § 2.3.13 6.1.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/13 Large Pointing Area for Option Selection3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>534 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/5 Large Pointing Area for Option Selection</span></text>
</content>
<name>3.1.3/5</name>
<script></script>
</card>
card_141740.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When menu selection is the primary means of sequence control, and especially if choices must be made from extensive lists of displayed control options, permit option selection by direct pointing (e.g., by touch display, lightpen, etc.). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Pointing directly at a displayed option guarantees good display-control compatibility. Users do not have to note associated option codes and enter them by key actions. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If a capability for direct pointing is not provided (e.g., if pointing involves separate manipulation of a mouse, or cursor positioning by key action), then for long menus it may prove faster to permit menu selection by keying associated option codes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
<text>1.1/12 Direct Pointing3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>533 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/4 Menu Selection by Pointing</span></text>
</content>
<name>3.1.3/4</name>
<script></script>
</card>
card_141451.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When multiple menu options are displayed in a list, display each option on a new line, i.e., format the list as a single column. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A single-column list format will aid scanning and assimilation of available options, especially for novice users. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Displaying options in several columns may be considered where shortage of display space dictates a compact format; if there are only a few options, those might be displayed in a single row. An interesting exception could be made for hierarchic menus, where a high-level menu might be shown in the left column of a display, accompanied by a lower-level menu in the right column whose options change to reflect whatever selection is currently made from the high-level menu. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.2.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/20 Single-Column List Format3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>532 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/3 Single-Column List Format</span></text>
</content>
<name>3.1.3/3</name>
<script></script>
</card>
card_141080.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Each menu display should permit only one selection by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Novice users will be confused by any more complicated procedure, such as a "Chinese menu" requiring one choice from Column A, one from Column B, etc. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 3.1.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.6.5</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>531 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/1 Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/2 Single Selection Per Menu</span></text>
</content>
<name>3.1.3/2</name>
<script></script>
</card>
card_141003.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider menu selection for tasks that involve choice among a constrained set of alternative actions, that require little entry of arbitrary data, where users may have little training, and where computer response is relatively fast. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Lengthy menus are often formatted as separate displays. Task-specific menus, however, can sometimes be incorporated effectively along with data displays, to provide a short list of appropriate control options. Menu selection is, of course, a generally good means for control entry by untrained users. Menus can be used in conjunction with other dialogue types, depending upon task requirements. Sometimes a menu selection might be clarified by a supplementary question-and-answer dialogue. If display output is slow, as on a printing terminal or on an electronic display constrained by a low-bandwidth channel, it may be tiresome for a user to wait for display of menu options, especially when selections must be made from several sequentially displayed menus. Under those conditions, experienced users may wish to by-pass menu selections in favor of direct command entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Displayed menus are commonly used for function selection in text processing, in graphic interaction, and a multitude of other applications. These sample displays represent portions of a large menu of wordprocessing functions. The good menu indicates the current position in ahierarchic menu structure. Different levels in the hierarchic structureare indicated by indentation. This menu offers (bolded) control actionsfor the most frequently used branch ("document management"), along withoptions to select other branches in the menu hierarchy. Selection ofanother branch would show a similar menu display, offering controlactions within the selected branch, but without offering the controlactions shown here for document management.The bad menu shows an alternative design for the same functions. Thebad menu lacks hierarchic structure, and does not distinguish betweencontrol actions and options that merely select further menus. The badmenu would require several successive menu selections in order to takefrequent actions.Good Sample Menu Display</span><span class="style8">|-------------------------------------------------------------|| W : WORD PROCESSING MENU GO= General Options || || D : DOCUMENT MANAGEMENT || C = Create || CF= Free format || CL= Letter || CM= Memo || CW= Wide format || E = Edit || P = Print || CO= COpy || RE= REname || DE= DElete || SP= SPelling check || I = Index || || T = Transferring documents || L = List processing || S = Status information || U = User profile || || || ENTER letter code to select action or another menu. || < ||-------------------------------------------------------------|</span><span class="style1">Bad Sample Menu Display</span><span class="style8">|-------------------------------------------------------------|| C = Create a new document || || CW = Create a new wide document || || D = Delete a document || || E = Edit an existing document || || F = Finished -- Exit || || I = Index of documents || || L = List Processing || || M = More Menu selections || || P = Print a document || || S = Spelling Error Detection || || || || Type the letters followed by a RETURN || < ||-------------------------------------------------------------|</span><span class="style1">This bad menu display violates in some degree several design guidelinesin this section:3.1.3/21 Logical ordering of menu options3.1.3/22 Logical grouping of menu options3.1.3/23 Logical ordering of grouped options3.1.3/24 Labeling grouped options3.1.3/25 Hierarchic menus for sequential selection3.1.3/27 Minimal steps in sequential menu selection3.1.3/28 Easy selection of important options3.1.3/30 Indicating current position in menu structure3.1.3/31 Control options distinct from menu branching3.1.3/34 Return to general menu</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.2.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>530 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/21 Logical ordering of menu options3.1.3/22 Logical grouping of menu options3.1.3/23 Logical ordering of grouped options3.1.3/24 Labeling grouped options3.1.3/25 Hierarchic menus for sequential selection3.1.3/27 Minimal steps in sequential menu selection3.1.3/28 Easy selection of important options3.1.3/30 Indicating current position in menu structure3.1.3/31 Control options distinct from menu branching3.1.3/34 Return to general menu</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.3 Dialogue Type - Menu Selection</span><span class="style21">3.1.3/1 Menu Selection</span></text>
</content>
<name>3.1.3/1</name>
<script></script>
</card>
card_140693.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that forms for control entry are consistent in format; their design should generally conform to guidelines for the design of data entry forms. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4 Data Forms2.2 Data Forms</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>529 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.2 Dialogue Type - Form Filling</span><span class="style21">3.1.2/4 Consistent Format for Control Forms</span></text>
</content>
<name>3.1.2/4</name>
<script></script>
</card>
card_140365.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider form filling as a means of displaying default values for the parameters in complex control entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Default parameters permit users to compose potentially complicated control entries by relatively simple actions. If defaults have been defined, they should be indicated to users. A displayed form permits a user to review (and confirm or change) default control values, just as a user might review displayed defaults for data entry. When only a few control parameters are involved, it may be feasible simply to prompt users with guidance messages rather than by displaying a control form. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.5/4 Layered Command Language</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>528 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.2 Dialogue Type - Form Filling</span><span class="style21">3.1.2/3 Defaults for Control Entry</span></text>
</content>
<name>3.1.2/3</name>
<script></script>
</card>
card_140040.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider form filling as an aid for composing complex control entries. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For a complex data retrieval request, a displayed form might indicate the various control parameters that could be specified. For a print request, a displayed form might help a user invoke the various format controls that are available. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>527 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.2 Dialogue Type - Form Filling</span><span class="style21">3.1.2/2 Form Filling for Control Entry</span></text>
</content>
<name>3.1.2/2</name>
<script></script>
</card>
card_139960.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider form filling for tasks where some flexibility in data entry is needed, such as the inclusion of optional as well as required items, where users will have moderate training, and/or where computer response may be slow. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Specific recommendations for the design of form-filling dialogues are presented in Section 1.4 for data entry and in Section 2.2 for data display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Form filling might be an appropriate dialogue type for a computer system that helped users calculate income tax obligations. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.3.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4 Data Forms2.2 Data Forms</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>526 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.2 Dialogue Type - Form Filling</span><span class="style21">3.1.2/1 Form Filling for Data Entry</span></text>
</content>
<name>3.1.2/1</name>
<script></script>
</card>
card_139656.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When questions prompt entry of data from a source document, ensure that the question sequence will match the data sequence in the source document. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/25 Form Compatible with Source Documents</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>525 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.1 Dialogue Type - Question and Answer</span><span class="style21">3.1.1/4 Sequence Compatible with Source Documents</span></text>
</content>
<name>3.1.1/4</name>
<script></script>
</card>
card_139506.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a series of computer-posed questions are interrelated, display answers to previous questions when those will provide context to help a user answer the current question. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not rely on a user to remember prior answers. Another way to request a related series of user entries is to use a form-filling dialogue rather than question-and-answer. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.4/3 Record of Prior Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>524 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.1 Dialogue Type - Question and Answer</span><span class="style21">3.1.1/3 Recapitulating Prior Answers</span></text>
</content>
<name>3.1.1/3</name>
<script></script>
</card>
card_139036.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In question-and-answer dialogues, display each question separately; do not require users to answer several questions at once. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user may become confused in trying to deal with several questions at once, particularly if the number of questions is variable from one transaction to another. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>523 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.1 Dialogue Type - Question and Answer</span><span class="style21">3.1.1/2 Questions Displayed Singly</span></text>
</content>
<name>3.1.1/2</name>
<script></script>
</card>
card_138960.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider question-and-answer dialogues for routine data entry tasks, where data items are known and their ordering can be constrained, where users will have little or no training, and where computer response is expected to be moderately fast. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Brief question-and-answer sequences can be used to supplement other dialogue types for special purposes, such as for LOG-ON sequences, or for resolving ambiguous control or data entries. Where computer response to any single user entry may be slow, then the aggregate time required to process a series of questions and answers may be very slow. In such a case, consider form filling as an alternative dialogue type, where the user can enter a set of related "answers" as a single transaction. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In the automated collection of medical history data, a computer might follow contingent branching logic in posing questions for patients to answer. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>522 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.1.1 Dialogue Type - Question and Answer</span><span class="style21">3.1.1/1 Question-and-Answer Dialogue</span></text>
</content>
<name>3.1.1/1</name>
<script></script>
</card>
card_138659.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the speed of computer response to user entries is appropriate to the type of dialogue; the response to menu selections, function keys, and most entries during graphic interaction should be immediate. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is generally thought that maximum acceptable delay for computer response to menu selection by lightpen is 1.0 second; for key activation is 0.1 second; for cursor positioning by lightpen (as in graphic line drawing) 0.1 second. If computer response time will be slow, consider choosing other dialogue types, such as command entry. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Consider task requirements and associated user characteristics when choosing dialogue type(s) and designing sequence control logic. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A simple dictum is, "Know the user." However, if user characteristics are variable, which is usually the case, then provide a variety of dialogue types based on analysis of task requirements. Choice of dialogue type(s) is a fundamental decision in interface design. Designers should consider that decision carefully. A poor choice can detract seriously from system usability and will be difficult to change later. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When untrained users must choose among a fixed set of options (as in the case of automated bank teller machines) labeled function keys might suffice for sequence control; when options may be chosen from a larger set (as in public information systems) menu selection will prove a more efficient dialogue type. When users must make data and control entries in an arbitrary order, perhaps mixed with queries (as in making flight reservations when talking with a customer), then some mixture of function keys and command entries will be required for effective operation. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When several users must interact with the system simultaneously, ensure that control entries by one user do not interfere with those of another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This requires careful interface design for applications where joint, coordinated actions must be made by a group of users. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.6.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.0/4 Protection from Interference by Other Users</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>519 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/22 Control by Simultaneous Users</span></text>
</content>
<name>3.0/22</name>
<script></script>
</card>
card_137821.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In situations where control lockout does occur, provide the user with an auxiliary means of control entry, such as a special function key, to abort a transaction causing extended lockout. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such an interrupt capability will be especially helpful if a user recognizes that an error has been made and wants to stop an unneeded transaction, acting like an UNDO command. Alternatively, for some transactions it may be helpful to design this interrupt as an END command that stops ongoing processing without canceling it. For example, if a user has asked the computer to scroll ahead in a long file display, that user may simply wish to stop at a certain point rather than returning to the beginning. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/6 RESTART Option</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>518 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/21 Interrupt to End Control Lockout</span></text>
</content>
<name>3.0/21</name>
<script></script>
</card>
card_137490.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If control entries must be delayed pending computer processing of prior entries, then indicate that delay to the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications it may be desirable to ensure that the keyboard and other control devices are automatically locked until the user can begin a new transaction. This would be true when processing the current transaction will affect the results of subsequent user actions. In other applications, it may be possible to permit users to continue work while previous transactions are still being processed. Deletion or change of a displayed cursor in itself may not be a sufficient indicator of keyboard lockout. Auditory signals will be particularly helpful to a skilled touch-typist, who may not look at the display when transcribing data entries. Following control lockout, computer readiness to accept further entries should be indicated to the user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If processing delay results in control lockout, that could be signaled by disappearance of the cursor from the display, or perhaps by a notable change in the shape of the cursor, accompanied by an auditory signal. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.1/4 Keyboard Lock</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>517 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/20 Indicating Control Lockout</span></text>
</content>
<name>3.0/20</name>
<script></script>
</card>
card_137250.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to make control entries as needed; a sequence of control entries should not be delayed by delays in computer response. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is recommended that control delays or lockouts not exceed 0.2 seconds. In some applications, however, longer delay may be tolerable, particularly if that has the effect of reducing variability in computer response time. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/4 Fast Response</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>516 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/19 Control Availability</span></text>
</content>
<name>3.0/19</name>
<script></script>
</card>
card_137154.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the speed of computer response to user control entries is appropriate to the transaction involved; in general, the response should be faster for those transactions perceived by a user to be simple. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Interface designers may need to consult with the intended system users to decide upon appropriate computer response times for different transactions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Computer response to a likely control entry, such as NEXT PAGE, should be within 0.5-1.0 second; response to other simple entries should be within 2.0 seconds; error messages should be displayed within 2-4 seconds. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Tables 2-3MIL-STD-1472C 1983 § Table XXIXFoley Van Dam 1982Miller 1968Shneiderman 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/4 Fast Response4.2/2 Fast Response4.3/11 Appropriate Response Time for Error Messages</text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to pace control entries, rather than requiring users to keep pace with computer processing or external events. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">User pacing will let control entries be made in accord with a user's current needs, attention span, and time available. When user-paced control does not seem feasible, as in critical process control applications, reconsider the general approach to task allocation and user interface design, perhaps providing greater system automation to ensure timely response. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the results of any control entry are compatible with user expectations, so that a change in the state or value of a controlled element is displayed in an expected or natural form. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Compatibility between user action and system response is an important concept in human engineering design. Interface designers should not assume that user expectations will match their own. User expectations can be discovered by interview, questionnaire, and/or prototype testing. Where no strong user expectations exist with respect to a particular design feature, then designers can help establish valid user expectations by careful consistency in interface design. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A control entry of NEXT PAGE should show the next frame of a current display, and should not jump off to some other internally defined "page" in the computer's data base. When the completion of a control entry is indicated by a special function key, that key should be labeled ENTER (or some functionally equivalent word) and should result in computer acknowledgment of the entry. </span></text>
<text>1.0/10 ENTER Key Labeling1.1/15 Compatible Control of Cursor Movement1.1/19 Compatible Control of Multiple Cursors3.0/6 Consistent User Actions4.2/1 Consistent Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>513 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/16 Compatibility with User Expectations</span></text>
</content>
<name>3.0/16</name>
<script></script>
</card>
card_136329.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When processing in response to a control entry is lengthy, give the user some positive indication of subsequent completion, and appropriate related information. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a user is currently involved in some new transaction, then completion of processing for a prior transaction should be indicated by nondisruptive display of an appropriate advisory message. If the outcome of a completed transaction may imply the need for further user action, that should be indicated to the user. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer acknowledges every control entry immediately; for every action by the user there should be some apparent reaction from the computer. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In particular, the absence of computer response is not an acceptable means of indicating that a control entry is being processed. "Immediately" as used in this guideline must be interpreted in relation to the response time requirements of different dialogue types. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Execution of a requested transaction might produce an immediately apparent result, as when a user requests NEXT PAGE and the next page is displayed. A message might indicate completion of a transaction, as when a user requests printout at a remote facility and the computer displays a confirming message </span><span class="style8">| AIRFIELD file has been sent to printer. |</span><span class="style1"> A message might indicate that execution is in progress or deferred, as when a user enters data and the computer displays an interim message </span><span class="style8">| AIRFIELD file is being updated. |</span><span class="style1"> A message might indicate that the control entry requires correction or confirmation, as when a user requests file display and the computer displays an error message </span><span class="style8">| "AIRFELD" file not recognized. |</span><span class="style1"> </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.3.1 4.3.2Engel Granda 1975 § 4.2.5MIL-STD-1472C 1983 § 5.15.5.2 5.15.5.3 5.15.2.1.3Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/3 Feedback During Data Entry1.0/12 Feedback for Completion of Data Entry1.0/13 Feedback for Repetitive Data Entries4.2/1 Consistent Feedback4.2/3 Feedback for Control Entries3.1 Dialogue Type</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>511 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/14 Feedback for Control Entries</span></text>
</content>
<name>3.0/14</name>
<script></script>
</card>
card_135926.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the wording and required format of control functions is reflected consistently in the wording of user guidance, including all labels, messages, and instructional material. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When selecting or composing control entries, a user will tend to mimic the vocabulary, format, and word order used in computer displays, including labels, error messages, HELP displays, etc. If displayed wording is consistent with required entries, a user will be more likely to make a correct entry on the first try. Consistency in wording will be particularly helpful for dialogues based on constrained natural language. If a designer begins by determining which words and formats users are likely to choose naturally, and then reinforces that usage by incorporating such wording in user guidance, much of a user's interaction with the computer will be predictable. Therefore the "natural language" need not accommodate the full range of possible entries, but only those entries which users are likely to make. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| To delete a paragraph, press | | DELETE and then PARAGRAPH. | </span><span class="style1">(Bad) </span><span class="style8">| If a paragraph must be erased, | | press DELETE and then PARAGRAPH. | </span><span class="style1">When the computer displays a file name, that name should be shown in a format that would be acceptable if the name were included in a command entry; do not display a capitalized name if the computer will not accept a capitalized entry. If a user must complete a control form to specify printer settings, the words used as labels on that form should also be used in any error messages and HELP displays which may guide that process. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Good Whiteside Wixon Jones 1984Mooers 1983Zoltan-Ford 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/7 Display Consistent with Entry Requirements3.1.7/1 Constrained Natural Language4.0/18 Wording Consistent with Control Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>510 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/13 Wording Consistent with User Guidance</span></text>
</content>
<name>3.0/13</name>
<script></script>
</card>
card_135523.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For interpreting user-composed control entries, treat upper and lower case letters as equivalent. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users find it difficult to remember whether upper or lower case letters are required, and so the interface design should not try to make such a distinction. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/27 Upper and Lower Case Equivalent1.3/10 Upper and Lower Case Equivalent in Search</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>509 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/12 Upper and Lower Case Equivalent</span></text>
</content>
<name>3.0/12</name>
<script></script>
</card>
card_135217.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When selecting names for sequence control functions, choose names that are semantically congruent with natural usage, especially for paired opposites. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user who learns one function name will assume that s/he can accomplish an opposite function by using a semantically opposite name. One implication is that names for sequence control functions should not be chosen independently. Another implication is that understanding a user's natural vocabulary is important for selecting good function names. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If one function name is UP, then DOWN (rather than LOWER, say) should accomplish an opposite function; PULL should be reversed by PUSH; FORWARD by BACKWARD; RIGHT by LEFT; IN by OUT; etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Carroll 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>508 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/11 Congruent Names for Control Functions</span></text>
</content>
<name>3.0/11</name>
<script></script>
</card>
card_134982.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For instructional material, such as display labeling, on-line guidance and other messages to users, adopt consistent terminology to refer to sequence control. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Various words and phrases might be used, such as "control input", "command entry", "instruction", "request", "function call", etc. The practice adopted in these guidelines is to call general sequence control actions "control entry". More specific terminology is sometimes used here, such as "command entry" for keyed control entries composed by the user, "code entry" for keyed selections from displayed menus, etc. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If the consequences of a control entry will differ depending upon context established by a prior action, then display some continuous indication of current context for reference by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not rely on the user always to remember prior actions, nor to understand their current implications. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If activating a DELETE key establishes a mode, so that subsequent selection of a PAGE key will erase a page of data rather than simply advancing to display the next page, then some indication of that established DELETE mode should be displayed to the user. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Design all displays so that features relevant to sequence control are distinctive in position and/or format. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Relevant features include displayed options, command entry areas, prompts, advisory messages, and other displayed items (titles, time signals, etc.) whose changes signal the results of control entries. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When designing a sequence of related transactions for some information handling task, employ task analysis to ensure that those transactions will constitute a logical unit or subtask from a user's viewpoint, and to determine what control options users will need at any point. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A logical unit to the user is not necessarily the same as a logical unit of the computer software that mediates the transaction sequence. It might be, for example, that a user should enter ten items of data in a single transaction, because those data all come from one particular paper form, even though the computer will use five of those items for one purpose and five items for another in its subsequent internal processing. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that sequence control actions are consistent in form and consequences; employ similar means to accomplish ends that are similar, from one transaction to the next, from one task to another, throughout the user interface. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In particular, there should be some standard, consistent routine for a user to initiate and terminate the transaction sequences that comprise different tasks. Do not require users to learn different command names to terminate different tasks, or remember to terminate one task by command and another by function key. Interface designers may sometimes be tempted to deviate from consistent control syntax in order to minimize keystrokes in a particular transaction. Or designers may wish to add a new, improved syntax for functions added later in system development. Though such inconsistencies may in each case be intended to help users, they will make all functions more difficult for users to learn. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Mooers 1983Reisner 1981</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/1 Standard Procedures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>503 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/6 Consistent User Actions</span></text>
</content>
<name>3.0/6</name>
<script></script>
</card>
card_133522.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to control transaction sequencing by explicit action; defer computer processing until an explicit user action has been taken. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If the computer interrupts a user, it pre-empts the initiative in sequence control, in effect forcing the user into an error correction (or some other) sequence conceived by the interface designer, and not necessarily a sequence that would be chosen by the user. Some interface designers devise computer interruptions that they suppose will help a user, as when they program a computer to complete a partial command automatically as soon as it recognizes the user's intended entry. Many users, however, will find unexpected computer interruptions more disconcerting than helpful, and may become confused at least momentarily as to just what they had intended. In general, computer detection of problems with current user entries can be negotiated at the conclusion of a transaction, before it is implemented. Nondisruptive alarms or advisory messages can be displayed to report computer monitoring of external events so that the user can choose when to deal with them. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In automated process control applications, emergency conditions may take precedence over current user transactions, and a computer-generated warning might interrupt user actions. In routine, repetitive data entry transactions, successful completion of one entry may lead automatically to initiation of the next, as in keying ZIP codes at an automated post office. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When a user is keying an extended data entry, the computer should not interrupt the user to require immediate correction of any entry error, but instead should wait for the user's ENTER action. When a user is composing a command to accomplish some transaction, the computer should not interrupt the user by responding as soon as it recognizes a partial entry, but instead should wait for the user's ENTER action. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action1.1/4 Explicit Activation1.4/1 Combined Entry of Related Data4.0/2 Explicit User Actions6.0/9 Control by Explicit User Action6.3/5 Explicit User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>502 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/5 Control by Explicit User Action</span></text>
</content>
<name>3.0/5</name>
<script></script>
</card>
card_133211.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to take initiative and control their interaction with the computer; try to anticipate user requirements and provide appropriate user control options and computer responses in all cases. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In most applications, a user should be able to interrupt or terminate any transaction once it has been initiated (see Section 3.3). Users will sometimes change their minds and decide that an initiated transaction is not what was wanted after all. Software logic should be "bulletproofed" to anticipate every possible action by a user, no matter how improbable, providing an appropriate computer response for random (or even malicious) inputs as well as for correct entries and likely errors. In particular, a dialogue should never reach a dead end with no further action available to the user. If a user makes an entry inappropriate to current processing logic, the computer should simply display an advisory message that the input cannot be recognized and indicate the available options as to what can be done next. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the means of sequence control are compatible with user skills, permitting simple step-by-step actions by beginners, but permitting more complex command entry by experienced users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Most systems will have users with varying levels of experience. Any particular user may become more expert with increasing experience, or perhaps less expert after a long period of disuse. Accommodating users of varying expertise will usually require a mixture of different dialogue types, with some means for smooth transition from one mode of dialogue to another. For instance, as a user comes to learn menu codes, s/he might be allowed to enter those codes without necessarily displaying a menu, i.e., those codes might also serve as commands. </span></text>
<text><span class="style19"> SEQUENCE CONTROL</span><span class="style20">3.0 General</span><span class="style21">3.0/3 Control Matched to User Skill</span></text>
</content>
<name>3.0/3</name>
<script></script>
</card>
card_132643.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that control actions are simple, particularly for real-time tasks requiring fast user response; control logic should permit completion of a transaction sequence with the minimum number of actions consistent with user abilities. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Shortcuts via direct commands should allow experienced users to by-pass intervening steps that may help beginners. The computer should be programmed to handle automatically any intervening processing that may be required, informing the user what has been done if that becomes necessary (as in the case of a detected error). </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">A destructive action will be less likely to be taken by mistake, if it is designed to be different or distinctive, requiring extra user actions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user should be able to print a display by simple request, without having to take a series of other actions first, such as calling for the display to be filed, specifying a file name, then calling for a print of that named file. For long, multipage displays, it should be possible to request a particular page directly, without having to take repetitive NEXT PAGE or PREV PAGE actions. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide flexible means of sequence control so that users can accomplish necessary transactions involving data entry, display, and transmission, or can obtain guidance as needed in connection with any transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Necessary transactions should be defined in task analysis prior to software design. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In scanning a multipage display the user should be able to go forward or back at will. If user interface design permits only forward steps, so that the user must cycle through an entire display series to reach a previous page, that design is deficient. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When data display requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to display functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Display characteristics that may need to be changed include those represented in these guidelines, namely, the types of data that can be displayed, formatting and coding logic, and the capabilities offered for display control. Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/2 Only Necessary Data Displayed2.0/8 User Control of Data Display2.0/11 Context for Displayed Data2.5/8 User-Defined Data Windows2.7.1/1 User Selection of Data for Display2.7.1/3 Meaningful Display Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>497 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.8 Design Change</span><span class="style21">2.8/1 Flexible Design for Data Display</span></text>
</content>
<name>2.8/1</name>
<script></script>
</card>
card_132094.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a window overlay temporarily obscures other displayed data, ensure that the obscured data are not permanently erased but will reappear if the overlay is later removed. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.1/10 Nondestructive Overlay</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>496 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/10 Nondestructive Overlay</span></text>
</content>
<name>2.7.5/10</name>
<script></script>
</card>
card_131749.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When control actions such as command entry may be taken by a user working within a window overlay, ensure that those control actions will be consistent from one window to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If controls in one window operate differently than in another, user confusion will be unavoidable. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Cursor positioning controls and data editing capabilities should operate consistently within all windows. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>495 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/9 Consistent Control Within Windows</span></text>
</content>
<name>2.7.5/9</name>
<script></script>
</card>
card_131503.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If several window overlays are displayed at once, provide some easy means for a user to shift among them to select which window shall be currently active. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The most direct method might be to allow a user to select a window by pointing anywhere within its displayed borders, but that action might be confused with the selection of a particular item within the window. Some designers provide a special symbol for window selection in the border itself. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>494 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/8 Easy Shifting Among Windows</span></text>
</content>
<name>2.7.5/8</name>
<script></script>
</card>
card_131245.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If several window overlays are displayed at once, indicate to the user in which window (if any) an action can currently be taken. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Adding window overlays to a display can increase the conceptual complexity of control actions as well as the difficulty of data assimilation. Consider a case in which several windows are shown, including some menu overlays and some data windows. There it is important to indicate to a user which window is currently "active", i.e., whether the next action will result in a menu selection or a data change. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A prominent cursor might be displayed in the currently active window, or perhaps the displayed border of an active window might be highlighted in some way. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/1 Highlighting Critical Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>493 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/7 Indicate Active Window</span></text>
</content>
<name>2.7.5/7</name>
<script></script>
</card>
card_131060.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user can select predefined window overlays, assign to each overlay an identifying label. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Labeling window overlays may help users request and recognize them, in the same way that display labeling can aid display selection. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide an easy means for a user to suppress the display of window overlays. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A requested guidance overlay might be removed by user selection of a RETURN function key; a menu overlay displayed under computer control might disappear automatically following user selection of an option from that menu. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.4 Display Control Suppression</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>491 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/5 Easy Suppression of Window Overlays</span></text>
</content>
<name>2.7.5/5</name>
<script></script>
</card>
card_130335.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the means provided users to control window overlays operate consistently from one display to another for each type of overlay. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Control of predefined windows may simply involve "opening" and "closing" them, by selection of displayed option labels or function keys. Control of user-defined windows may require user specification of window contents, window size and positioning on the display. Such window control must be learned by a user, and consistent design of control logic will aid that learning. Some advocates of window overlays predict that standard methods of window control will become part of the basic support software for user interface design. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>490 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/4 Consistent Window Control</span></text>
</content>
<name>2.7.5/4</name>
<script></script>
</card>
card_130266.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the need to view several different kinds of data jointly cannot be determined in advance, allow a user to specify and select separate data windows that will share a single display frame. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users may abuse such a capability for arbitrary window definition, adding so many windows to a display that the resulting hodgepodge defies interpretation. A designer can do little to prevent that. However, the designer can try to ensure that the means for window creation and control are made as efficient as possible. Depending upon user needs (and system capability), data windows might appear simultaneously as segments of a joint display, might be overlaid in varying degrees so as to obscure one another, or might be displayed sequentially at the user's option. In the latter condition, multiple display windows will differ little from multiple display pages, except perhaps in speed of sequential access. This recommendation assumes that it is mostly data overlays which a user will want to create. Other kinds of window overlays would usually be offered under computer control, such as those providing error messages and other forms of user guidance. It is possible, however, that a user might wish to define certain kinds of non-data windows, such as an overlay of "favorite" menu options, or an overlaid guidance "memo" composed for the user's own purposes. Perhaps a user should be allowed to create those kinds of window overlays as well. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.5/8 User-Defined Data Windows</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>489 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/3 User-Specified Windows</span></text>
</content>
<name>2.7.5/3</name>
<script></script>
</card>
card_129816.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the value of particular window overlays can be determined during interface design, those overlays should be predefined and offered to users under computer control. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The aim here is to allow a user to select window overlays that have already been designed, rather than having to specify a desired window from scratch. User display control should be kept as simple as possible, so that a user can spend time assimilating data instead of manipulating the display of data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A menu of currently appropriate control options might be superimposed on a current display by user selection of the displayed menu title. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>488 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/2 Predefined Windows</span></text>
</content>
<name>2.7.5/2</name>
<script></script>
</card>
card_129779.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When it is necessary to add requested data or other features temporarily to a current display, consider providing window overlays for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here temporary window overlays should be distinguished from the more stable "windows" consistently provided in display formatting, such as the various defined display areas that might be dedicated to showing the display title, a date-time group, user prompting, a composed control entry, an error message, etc. Window overlays can be used to show data of temporary or extraneous interest. By contrast, if a set of data must be viewed continuously or in an integrated display with other data, then that data set should be available as a selectable data category. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">On a map display, if a user requests detailed data about a particular location, the computer might display an overlaid window with tabular or textual description, which could later be removed by user action. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.1/5 Selectable Data Categories2.5 Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>487 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.5 Display Control - Window Overlays</span><span class="style21">2.7.5/1 Temporary Window Overlays</span></text>
</content>
<name>2.7.5/1</name>
<script></script>
</card>
card_129350.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data have been suppressed from a display, provide users with some means to quickly restore the display to its complete, originally generated form. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a function key is used to restore suppressed data, that key action should have no other consequences. For instance, if a user must press RETURN to restore suppressed data, that key should only restore data and should not also move a displayed cursor to some other position. In some applications, it may be desirable to restore suppressed data automatically, after expiration of a predetermined time-out, rather than relying on a user to remember to do it. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>486 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.4 Display Control - Suppression</span><span class="style21">2.7.4/4 Resuming Display of Suppressed Data</span></text>
</content>
<name>2.7.4/4</name>
<script></script>
</card>
card_129024.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data have been suppressed from a display, warn users if some significant (but not displayed) change is detected in the computer processing of new data. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>485 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.4 Display Control - Suppression</span><span class="style21">2.7.4/3 Signaling Changes to Suppressed Data</span></text>
</content>
<name>2.7.4/3</name>
<script></script>
</card>
card_128947.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data have been suppressed from a display, annotate the display with some appropriate label to remind users that data have been suppressed. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>484 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.4 Display Control - Suppression</span><span class="style21">2.7.4/2 Labeling Display Suppression</span></text>
</content>
<name>2.7.4/2</name>
<script></script>
</card>
card_128570.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When standard data displays are used for special purposes, allow users to temporarily suppress the display of data not needed for the current task. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Data selections made originally for one purpose may not be appropriate for another. When task requirements shift rapidly, it may be more efficient to suppress temporarily the display of unneeded data categories, rather than to regenerate a display with different selection criteria. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/1 Necessary Data Displayed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>483 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.4 Display Control - Suppression</span><span class="style21">2.7.4/1 Temporary Suppression of Displayed Data</span></text>
</content>
<name>2.7.4/1</name>
<script></script>
</card>
card_128465.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">To help a user understand and respond effectively to complex data changes, consider displaying a prediction of future data states based on computer analysis of an appropriate model of the data dynamics. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The concept of prediction display extends the practice of dynamic display update, from simply showing recent and current data states, to anticipate future changes in data. In effect, a computer can iterate in "fast time" changes in a dynamic data model, and then display its current prediction of future real-time changes. The usefulness of such prediction will depend upon the accuracy of the underlying data model. As it happens, where prediction display can help users, as in complex vehicular control or process control applications, the dynamics of process change are often defined sufficiently well to permit valid computer modeling. A consistent logic should be adopted for computer modeling and prediction in relation to possible user action. For dynamic control applications, one feasible logic is for a computer to predict and display the future consequences if the user persists in the current control action. As an alternative, a computer might predict and display the consequences if the user were to cease any control action. Either logic could prove helpful. But whichever is adopted should be used consistently. Prediction displays should be formatted to distinguish clearly between actual current data and extrapolated future data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Prediction display might be used to aid the control of any rapidly changing process involving complex dynamics, such as depth control for a high-performance submarine. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>482 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/9 Prediction Display</span></text>
</content>
<name>2.7.3/9</name>
<script></script>
</card>
card_128139.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display being updated in real time has been frozen, and then a user elects to resume update, resume display update at the current real-time point unless otherwise specified by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications, a user might wish to resume display update at the point of stoppage, and so display change would thenceforth lag real-time data change. Or perhaps a user might choose to see a speeded "replay" of interim changes to regain current display status. In practice, however, such options might risk confusion. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.4.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>481 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/8 Resuming Update After Display Freeze</span></text>
</content>
<name>2.7.3/8</name>
<script></script>
</card>
card_127821.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display being updated in real time has been frozen, warn users if some significant (but not displayed) change is detected in the computer processing of new data. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/13 Displayed Context</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>480 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/7 Signaling Changes to Frozen Data</span></text>
</content>
<name>2.7.3/7</name>
<script></script>
</card>
card_127703.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display has been frozen, annotate that display with some appropriate label to remind users of its frozen status. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.4.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/13 Displayed Context</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>479 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/6 Labeling Display Freeze</span></text>
</content>
<name>2.7.3/6</name>
<script></script>
</card>
card_127322.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When displayed data are automatically updated, allow users to stop the process (by "freeze" or "stop action") at any point, in order to examine changed data more deliberately. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For some applications, it might also prove helpful if a user could step incrementally forward or back in a time sequence, in order to examine data changes frame by frame. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For an operations monitoring task, requirements may dictate that current data changes be continuously viewed; in such a case, display freeze might be useful during some subsequent playback of recorded data for purposes of operational analysis. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.4.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>478 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/5 Display Freeze</span></text>
</content>
<name>2.7.3/5</name>
<script></script>
</card>
card_127118.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user must visually integrate changing patterns on a graphic display, update the data at a rate appropriate to human perceptual abilities for that kind of data change. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Slowly developing patterns may be seen more easily with time compression, i.e., with rapid display of sequentially stored data frames. Fast changing data may require time expansion, i.e., slowed output, to aid pattern perception. For critical applications, experiment with prototype displays to determine proper timing. In some applications it may help to allow a user to control the speed for update of displayed data. In applications where the timing of display update is variable, it may help to indicate the currently selected time scale on the display. Similar considerations apply to auditory displays, where speeding or slowing sound signals may aid pattern recognition. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Effective display of changing radar data for track detection and monitoring requires repeated, sequential output of stored data frames, and the timing of successive frames is critical for optimizing pattern perception. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.6.3Chao 1985Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>477 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/4 Visual Integration of Changing Graphics</span></text>
</content>
<name>2.7.3/4</name>
<script></script>
</card>
card_126938.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If users must accurately read changing data values, ensure that those data are displayed long enough to be read. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A current design standard specifies that for accurate reading, data should be displayed in a fixed position and updated no more than once per second. In some applications, however, a slower update rate may be required. When in doubt, test user performance with prototype displays to determine appropriate update rates. If users need only to monitor general trends in changing data values, and do not need to take exact readings, somewhat faster update rates may be acceptable. Again, prototype testing will sometimes be needed to determine appropriate update rates. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.4.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>476 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/3 Readability of Changing Data</span></text>
</content>
<name>2.7.3/3</name>
<script></script>
</card>
card_126650.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data have changed following automatic display update, consider highlighting those data changes temporarily. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The desirable interval for highlighting changed data will depend on the importance of those data. If data changes imply a need for special user attention, then highlighting might continue until the user takes some specific acknowledgement action. Otherwise, highlighting might be removed after several seconds, or might continue until a user takes some other control action. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A change in a critical data item might be highlighted with reverse video, or might be marked with a blinking symbol. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/1 Highlighting Critical Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>475 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/2 Highlighting Changed Data</span></text>
</content>
<name>2.7.3/2</name>
<script></script>
</card>
card_126338.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When displayed data are changing as a result of external events, a user should be able to request automatic update (computer regeneration) of changed data, and be able to control the update rate. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In an operations monitoring task, requirements may dictate the circumstances and rate of display updating. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.4.2</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>474 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.3 Display Control - Update</span><span class="style21">2.7.3/1 Automatic Display Update</span></text>
</content>
<name>2.7.3/1</name>
<script></script>
</card>
card_125990.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user is allowed to pan over an extended display, or zoom for display expansion, provide some easy means for the user to return to normal display coverage. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user who has panned to some special area in an extended display, or who has expanded a display to examine some particular section in detail, may suddenly need to return quickly to normal display coverage. Perhaps the user has received an alerting message requiring attention to another portion of the display. Quick return to normal coverage will allow the user to re-establish a familiar orientation to the display as a whole. Here normal coverage might always be defined as that data coverage shown when a display was initially generated. Or it might be desirable in some instances to allow a user to specify what is to be considered normal coverage for any particular display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Return to normal display coverage might be accomplished by a function key labeled RETURN, or perhaps RESET. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>473 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/17 Return to Normal Display Coverage</span></text>
</content>
<name>2.7.2/17</name>
<script></script>
</card>
card_125942.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that framing functions perform integrally so that panning and/or zooming will affect all displayed data in the same way. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">On a situation display, zooming should expand background data such as geographic boundaries to the same scale as the expansion of overlaid "active" data. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>472 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/16 Framing Integrally for All Data</span></text>
</content>
<name>2.7.2/16</name>
<script></script>
</card>
card_125556.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display has been panned and/or expanded from its normal coverage, provide some graphic indicator of the position in the overall display of the currently visible section. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A graphic indication of the current coverage of a panned or expanded display will provide some visual context to help a user maintain a conceptual orientation between the visible part and the whole display from which that part has been excerpted. In some special applications it may be possible to provide a user with two separate display screens, one to show an overview for general reference, and the other to show an expanded portion of that overview display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a corner of the display frame the computer might show a rectangle representing the overall display, in which a smaller rectangle is placed to indicate the position and extent of the currently visible portion of that display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/17 Show Overview Position of Visible Section2.4.8/11 Show Overview Position of Visible Section</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>471 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/15 Show Overview Position of Visible Section</span></text>
</content>
<name>2.7.2/15</name>
<script></script>
</card>
card_125388.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display has been expanded from its normal coverage, provide some scale indicator of the expansion factor. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications it may be helpful to show the scale even for a display with normal, unexpanded coverage. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A linear indicator of current map scale might be shown in the margin, or perhaps simply a numeric indication of the display expansion factor (e.g., </span><span class="style8">| x4 |</span><span class="style1">). </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/16 Show Changing Scale</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>470 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/14 Show Changing Scale</span></text>
</content>
<name>2.7.2/14</name>
<script></script>
</card>
card_125140.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user may need to perceive displayed data relations more accurately, or to view data in pictures, diagrams, maps, etc. in greater detail, provide a zooming capability that allows the user to expand the display of any selected area. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Zooming can increase display spacing among crowded data items so that they can be perceived better. Thus an air traffic controller might expand a portion of a situation display to see more clearly the spacing of converging tracks that threaten a collision. Zooming can increase the degree of detail, i.e., can add data to a display. Thus a user might expand a city map to see detailed road structures that are not shown in a small-scale map. When used this way, a zooming capability implies that data can be "layered" hierarchically at different levels of aggregation, which may require complex data files and data management techniques. Zooming might be implemented as a continuous function, by which a display can be expanded to any degree, analogous to a continuous panning capability. Or zooming might be implemented in discrete increments, as in increasing the magnification of an optical instrument to x2, x4, etc. Incremental zooming, with abrupt changes in display scale, may tend to disorient a user, but might prove acceptable in some applications. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/15 Zooming for Display Expansion</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>469 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/13 Zooming for Display Expansion</span></text>
</content>
<name>2.7.2/13</name>
<script></script>
</card>
card_124683.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display exceeds the capacity of a single frame, in terms of the required extent and detail of coverage, consider providing users a capability to pan the display frame over the data in order to examine different areas of current interest. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A panning capability, sometimes called display "offset", can allow a user to move continuously over an extended display in any desired direction, without encountering any internal boundaries imposed by predefined display framing. Panning control might be accomplished by some continuous-action device such as a joystick, perhaps "dragging" a displayed framing element and then requesting display regeneration. There is some risk that a user might become disoriented in this process. An alternative approach is to define discrete pages or sections of a large display, assign those sections identifying labels, and allow a user to specify directly which section should be displayed. This approach requires the user to pay specific attention to the labeling of different sections, which extra effort may help maintain orientation to the display as a whole. One risk in this approach, for a continuous display such as a map, is that an area of interest might be at a boundary where none of the sections provide adequate coverage. Thus some degree of overlapped coverage might be needed at the boundaries of displayed sections. For some applications, it might prove helpful to allow a user to specify a particular location (such as a point on a map) and then automatically offset the display frame to be centered around that location. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.6/3 Linking Sectional Diagrams2.4.8/10 Panning for Flexible Display Framing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>468 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/12 Panning for Flexible Display Framing</span></text>
</content>
<name>2.7.2/12</name>
<script></script>
</card>
card_124471.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a scrolling orientation is maintained consistently, choose names for display framing functions that refer to movement of the data being displayed, and not to movement of the display frame (or window). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In this case, the command "Up 10" should mean that displayed data will move up ten lines behind the (conceptually fixed) display frame, with the effect that ten lines of previous data will disappear from the top of the display, and ten lines of subsequent data will appear at the bottom. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.16</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>467 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/11 Labeling Scrolling Functions</span></text>
</content>
<name>2.7.2/11</name>
<script></script>
</card>
card_124278.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a panning orientation is maintained consistently, choose names for display framing functions that refer to movement of the display frame (or window) and not to movement of the displayed data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In this case, the command "Up 10" should mean that the display frame will move up ten lines, with the effect that ten lines of previous data will appear at the top of the display, and ten lines of subsequent data will disappear at the bottom. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>466 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/10 Labeling Panning Functions</span></text>
</content>
<name>2.7.2/10</name>
<script></script>
</card>
card_124079.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user will access different systems with different conventions for panning or scrolling, in user instructions, key labels, etc., always refer to display framing in functional terms (e.g., "forward" and "back", or "next" and "previous") and avoid wording that implies spatial orientation (e.g., "up" and "down"). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Control of display framing functions might be implemented by keys marked with arrows, to avoid verbal labels altogether. Note that "forward" and "back" are potentially ambiguous because of the contradictory use of those words in referring to movement within books. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>465 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/9 Functional Labeling for Display Framing</span></text>
</content>
<name>2.7.2/9</name>
<script></script>
</card>
card_123755.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where a user can move a cursor freely about a page of displayed data, adopt panning rather than scrolling as the conceptual basis of display framing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Since displayed data will be perceived as fixed during free cursor movement, considerations of joint compatibility suggest that displayed data remain conceptually fixed during movement of a display frame or window. Indeed, it might be possible to use the same arrow-labeled function keys to control both cursor movement and panning. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Full-screen editing is a common application involving free cursor movement. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Morrill Davies 1961</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/3 Free Cursor Movement</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>464 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/8 Panning with Free Cursor Movement</span></text>
</content>
<name>2.7.2/8</name>
<script></script>
</card>
card_123546.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt a consistent orientation for display framing throughout interface design, so that users can either 1) conceive the display frame as a window moving over a fixed array of data, here called "panning", or 2) conceive data as moving behind a fixed display frame, commonly called "scrolling". </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Ideally a consistent orientation for display framing would be maintained across all systems. Certainly that orientation should be consistent within any one system. A user can adapt to either concept, if it is maintained consistently. Both concepts have some precedent in experience. Moving a camera across a fixed scene illustrates panning. Moving a specimen beneath the fixed eyepiece of a microscope illustrates scrolling. Tests seem to indicate that panning is the more natural concept for inexperienced users, causing fewer errors, and hence is the preferred option when other considerations are equal. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Bury Boyle Evey Neal 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>463 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/7 Consistent Orientation - Panning vs. Scrolling</span></text>
</content>
<name>2.7.2/7</name>
<script></script>
</card>
card_123147.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When display output is more than one page, annotate each page to indicate display continuation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When a display extends over just a few pages, and when a user is not expected to care about any particular page, then it may be sufficient to identify the pages | first | | continued | | last | rather than assigning them numbers. A recommended format is to identify pages by a note immediately to the right of the display title. With such a consistent location, the page note might be displayed in dimmer characters. Leading zeros should not be used in the display of page numbers. If a large display output is viewed by continuous panning/scrolling rather than by discrete paging, then some other means must be found to label that portion of the display which is currently visible. Some sort of graphic indicator might be inset at the margin of the display frame to suggest current location. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The phrase </span><span class="style8">| page x of y |</span><span class="style1"> is commonly used for this purpose. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When lists or tables are of variable length, and may extend beyond the limits of one display frame, inform a user when data are continued on another page and when data are concluded on the present page. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Short lists whose conclusion is evident from the display format need not be annotated in this way. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Incomplete lists might be marked </span><span class="style8">| continued on next page| </span><span class="style1">or </span><span class="style8">| continued | </span><span class="style1">or </span><span class="style8">| more | </span><span class="style1">while concluding lists might display a note </span><span class="style8">| end of list | </span><span class="style1">or </span><span class="style8">| end | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.9.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.2/7 Identifying Multipage Displays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>461 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/5 Annotating Display of Continued Data</span></text>
</content>
<name>2.7.2/5</name>
<script></script>
</card>
card_122831.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For a large table that exceeds the capacity of one display frame, ensure that users can see column headings and row labels in all displayed sections of the table. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/4 Labels for Multipage Tables</span></text>
</content>
<name>2.7.2/4</name>
<script></script>
</card>
card_122494.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a list of numbered items exceeds one display page, number the items continuously in relation to the first item on the first page. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.10</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>459 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/3 Continuous Numbering in Multipage Lists</span></text>
</content>
<name>2.7.2/3</name>
<script></script>
</card>
card_122298.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When requested data exceed the capacity of a single display frame, give users some easy means to move back and forth over displayed material by paging or panning/scrolling. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Note that critical data requiring integrated display for effective assimilation should be included in a single frame, and not dispersed over several pages. Paging is acceptable when the user is looking for a specific data item, but not when the user must discern some relationship in a set of data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Dedicated function keys might be provided for paging forward and back. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In designing displays, include all data relevant to a user's current transaction in one display frame or page. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation is particularly important when critical data items must be compared by a user. Do not rely on a user to remember data accurately from one display frame to another. If a user requests a display output that exceeds the capacity of a single frame, than it is obviously not possible for any designer to ensure an integrated display. However a designer can mitigate the problems associated with use of extended displays, by providing effective means for identifying and controlling sequential access to different portions of the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.4.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/1 Necessary Data Displayed2.5/5 Related Data on Same Page2.5/7 Integrated Display4.0/5 Only Necessary Information Displayed4.4/1 Guidance Information Always Available</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>457 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.2 Display Control - Framing</span><span class="style21">2.7.2/1 Integrated Display</span></text>
</content>
<name>2.7.2/1</name>
<script></script>
</card>
card_121710.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When displayed data are of potential long-term interest, give users some easy means to print paper copies locally, within security restraints. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users should not have to remember displayed data. Optional printout allows a user to record data from one display to compare with another, and so deal with situations where a designer has not anticipated the need for such comparison. A user should not have to take notes or transcribe displayed data manually. That practice underutilizes the data handling potential of the computer, and risks transcription errors by the user. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If changing data elements temporarily overlay and obscure other display data, ensure that the obscured data are not permanently erased but will reappear if the overlaid data are later removed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">To govern the appearance of data overlay, it may be necessary to establish a hierarchy of data categories to determine which will be shown when displayed in combination. Actively changing data will generally take priority over more stable background/reference data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a situation display moving track data may temporarily obscure stable background data. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When the computer must regenerate a display to update changed data, erase old data items before adding new data items to the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The aim here is to avoid any momentary user confusion that might result from watching portions of old data being overwritten and partially overlapped by portions of new data. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>454 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/9 Initial Erasure to Replace Changed Data</span></text>
</content>
<name>2.7.1/9</name>
<script></script>
</card>
card_120931.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where the computer must regenerate a display to update changed data items, consider regenerating only those changed items if that will speed display output. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The critical design issue here is speed of display. It may be easier for the computer to regenerate an entire display than to change just one item. But if that results in slower computer response to the user, then the added work of selective display regeneration may be worth-while. Partial display regeneration to show data changes should only be used, of course, when that can be accomplished without erasing unchanged data. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>453 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/8 Regenerating Changed Data</span></text>
</content>
<name>2.7.1/8</name>
<script></script>
</card>
card_120728.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If display generation is slow, notify the user when display output is complete. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A nonobtrusive auditory signal such as a chime should suffice for this purpose. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>452 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/7 Signaling Completion of Display Output</span></text>
</content>
<name>2.7.1/7</name>
<script></script>
</card>
card_120393.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that system response to simple requests for data display take no more than 0.5 to 1.0 second. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When display output is paced in segments (blocks, paragraphs, etc.), response time refers to output of the first segment. The recommended response time of 0.5 to 1.0 second should apply when a user makes a request (usually perceived as "simple") for the next page of a multipage display, or when a display begins to move in response to a scrolling command. The response to a request for a new display may take somewhat longer, perhaps 2 to 10 seconds, particularly if the user perceives such a request to involve more complicated operations, such as accessing different files, transforming data, etc. The desirability of rapid display generation is often discounted in practice, particularly for general purpose, time-shared systems where other practical design considerations may dictate slower computer response. For dedicated systems, however, those designed to help perform defined information handling tasks, rapid response should be an explicit design goal, with computer output capabilities designed accordingly. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/14 Feedback for Control Entries4.2/2 Fast Response4.2/3 Feedback for Control Entries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>451 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/6 Fast Response to Display Request</span></text>
</content>
<name>2.7.1/6</name>
<script></script>
</card>
card_120187.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If the particular data categories required at different stages in a user's job cannot be exactly predicted, allow the user to select the categories needed for any information handling task. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation does not lessen the designer's responsibility for determining user needs. Where user information requirements can be defined, displays should be designed to provide necessary data. User selection from available data categories may represent desirable flexibility to meet changing task requirements. However, there is a risk of "data indigestion" if a user selects the wrong categories or too many categories. Categories of selectable data might include relatively stable elements (e.g., defined flight paths, zones of radar coverage, etc.) as well as the variable elements that represent changing data (e.g., aircraft tracks). If auxiliary coding is adopted for different data categories, such as shape coding of symbols, code values should be chosen to be distinctive for any likely combination of displayed categories. Users should be provided a ready reminder of what data categories are available, and an easy means of selecting (or suppressing) displayed categories. This implies category selection by menu or function keys. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In monitoring aircraft separation for collision avoidance, a user might choose to display selectively the aircraft tracks within a particular altitude zone. To help identify an unrecognized aircraft track, a user might choose to add flight plan data temporarily to an air traffic display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.8/17 Selectable Data Categories</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>450 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/5 Selectable Data Categories</span></text>
</content>
<name>2.7.1/5</name>
<script></script>
</card>
card_119871.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Place the identifying label used for display selection in a prominent and consistent location on each display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The top left corner of the display might be used for this purpose. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/4 Consistent Format for Display Labels</span></text>
</content>
<name>2.7.1/4</name>
<script></script>
</card>
card_119569.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">The display identification label should be unique, short, but meaningful enough to be remembered easily. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As conceived here, the display label serves as a shorthand identification. The label does not take the place of a full, descriptive title. The full title would be displayed separately. Where flexibility is desired, it may be good practice to let a user assign names to the particular sets of data that constitute commonly used displays, either as formal names or else as nicknames associated by the computer with the formal names. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.5/10 Display Title at Top4.2/6 Display Identification</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>448 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/3 Meaningful Display Labels</span></text>
</content>
<name>2.7.1/3</name>
<script></script>
</card>
card_119528.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user will select data displays, assign to each display an identifying label, i.e., an alphanumeric code or abbreviation that can facilitate display requests by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An identifying label will help users remember different displays and provide a convenient means for requesting them. Even in systems where users exercise little initiative in data selection, where displays are largely configured in advance by designers, some kind of display identification will help users understand the displayed consequences of sequence control actions. It may also the helpful to include an identifying label in any separately selected "window" that might be overlaid on another display, as noted in Section 2.7.5. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For general data processing systems, allow users to specify the data for displayed output; for specific information handling applications, allow users to select data for display as needed to meet task requirements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Flexibility of data selection by users can be exercised, of course, only within the limits of what data are available within a computer system, and what means for data selection have been provided by the designer. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/2 Only Necessary Data Displayed2.0/8 User Control of Data Display2.8/1 Flexible Design for Data Display</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>446 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7.1 Display Control - Selection</span><span class="style21">2.7.1/1 User Selection of Data for Display</span></text>
</content>
<name>2.7.1/1</name>
<script></script>
</card>
card_119028.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When user information requirements cannot be exactly defined by the designer, allow users to tailor displays flexibly on line by controlling data selection, data coverage within a display frame, data updating and suppression. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here user control of data display is distinguished from the broader control of transaction sequences covered in Section 3 of these guidelines. Display control by users is certainly a necessary capability in general-purpose data processing systems. In a designed information system, i.e., a system created to perform specific tasks, the need for display control by users will depend on the degree to which users' information requirements can be anticipated by designers. In effect, if you know what data the system users will need, then design the displays to provide those data. If you are uncertain about user requirements, then provide users with some flexibility to control display configuration themselves. Some more specialized methods of display control (e.g., rotation) are discussed elsewhere in guidelines pertaining to graphic data entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/1 Necessary Data Displayed2.0/8 User Control of Data Display2.8/1 Flexible Design for Data Display1.6 Graphics</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>445 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.7 Display Control</span><span class="style21">2.7/1 Flexible Display Control by User</span></text>
</content>
<name>2.7/1</name>
<script></script>
</card>
card_118720.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If computer-generated speech output is used for auditory display, add a special alerting signal to introduce voice alarms and warning messages in order to distinguish them from routine advisory messages. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hakkinen Williges 1984Simpson Williams 1980</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/26 Speech Output4.0/27 Limited Number of Spoken Messages4.0/28 Simple Spoken Messages4.0/29 Distinctive Spoken Warnings</text>
<text><span class="style10">Γêå Statement</span><span class="style1">For auditory displays with voice output, consider using different voices to distinguish different categories of data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">At least two voices, male and female, could be readily distinguished, and perhaps more depending upon fidelity of auditory output, and listening conditions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Simpson etal 1985Smith Goodwin 1970</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>443 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/41 Voice Coding</span></text>
</content>
<name>2.6/41</name>
<script></script>
</card>
card_118020.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For auditory displays, employ distinctive sounds to code items requiring special user attention. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Tones may be presented in sequence to enlarge the signal repertoire. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A variety of signals may be available, including sirens, bells, chimes, buzzers, and tones of different frequency. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Smith Goodwin 1970</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.3/19 Alarm Coding</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>442 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/40 Distinctive Auditory Coding</span></text>
</content>
<name>2.6/40</name>
<script></script>
</card>
card_117906.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider auditory displays as a means of supplementing visual display, or as an alternative means of data output in applications where visual displays are not feasible. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As compared with visual displays, an auditory display offers a potential advantage in attracting a user's attention; a user does not have to "listen at" an auditory display in order to hear it. On the other hand, auditory displays suffer from a number of comparative disadvantages. Auditory displays generally do not offer as great a range of coding options. Auditory displays do not permit easy scanning to discern critical data items, or items that may have been missed at first listening. For human listeners with normal vision, auditory displays do not provide a natural representation of spatial relations. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Auditory display may be impractical in situations where high ambient noise prevents accurate listening. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Auditory signals may be helpful in alerting users to critical changes in a visual display. Auditory output might be used to permit telephone access to computer-stored data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.9.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/30 Auditory Signals for Alerting Users4.0/26 Speech Output4.0/27 Limited Number of Spoken Messages4.0/28 Simple Spoken Messages4.0/29 Distinctive Spoken Warnings</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>441 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/39 Auditory Coding</span></text>
</content>
<name>2.6/39</name>
<script></script>
</card>
card_117688.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider other visual coding dimensions for special display applications, including variation in texture, focus, and motion. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Texture can be useful for area coding in graphic displays. Only two levels of focus are feasible, clear and blurred, with the risk that blurred items will be illegible. Perhaps 2 to 10 degrees of motion might be distinguished, in applications where motion is an appropriate and feasible means of display coding. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4 Graphics</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>440 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/38 Coding with Texture, Focus, Motion</span></text>
</content>
<name>2.6/38</name>
<script></script>
</card>
card_117327.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When blink coding is used, select a blink rate in the range from 2 to 5 Hz, with a minimum duty cycle (ON interval) of 50 percent. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Although equal ON and OFF intervals are often specified, an effective code can probably be provided even when the OFF interval is considerably shorter than the ON (a "wink" rather than a blink), as in occulting lights used for Navy signaling. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must read a displayed item that is blink coded, consider adding an extra symbol such as an asterisk to mark the item, and then blinking that marker symbol rather than blinking the item itself. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will draw attention to an item without detracting from its legibility. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Consider blink coding when a displayed item implies an urgent need for user attention. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If used sparingly, blinking symbols are effective in calling a user's attention to displayed items of unusual significance. Blinking characters may have somewhat reduced legibility, and may cause visual fatigue if used too much. Perhaps three or four blink rates might be reliably distinguished, but it will probably prove safer to use blinking as a two-level code, blinking versus nonblinking. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Use saturated blue only for background features in a display, and not for critical data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The human eye is not equally sensitive to all colors, nor are its optics color-corrected. Blue symbols appear dimmer than others, and are more difficult to focus. If blue must be used for displayed data, use a desaturated blue or cyan in order to make the data more legible. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Saturated blue might be used for shading background areas in graphic displays, where its lower apparent brightness could possibly be of benefit. Or saturated blue might be used to display a background grid or familiar scale on a graphic display. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/34 Saturated Blue for Background Color</span></text>
</content>
<name>2.6/34</name>
<script></script>
</card>
card_116473.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use brighter and/or more saturated colors when it is necessary to draw a user's attention to critical data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">On some display equipment, designers can vary the intensity as well as the saturation for individual hues. On those displays, both intensity and saturation can be used to draw a user's attention to critical data. Although saturated and/or intense hues are useful for drawing a user's attention, their overuse will result in a display which is garish and difficult to view for long periods. When deciding the desired saturation of any given display color, consider the ambient lighting under which the display will be viewed. Colors that appear highly saturated in a darkened room will appear less saturated when viewed under high ambient illumination. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>435 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/33 Brightness and Saturation to Draw Attention</span></text>
</content>
<name>2.6/33</name>
<script></script>
</card>
card_116158.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose colors for coding based on conventional associations with particular colors. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Other associations can be learned by a user if color coding is applied consistently. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a display of accounting data, negative numbers might be shown as red, corresponding to past use of red ink for that purpose. Red is associated with danger in our society, and is an appropriate color for alarm conditions. Yellow is associated with caution, and might be used for alerting messages or to denote changed data. Green is associated with normal "go ahead" conditions, and might be used for routine data display. White is a color with neutral association, which might be used for general data display purposes. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/32 Conventional Assignment of Color Codes</span></text>
</content>
<name>2.6/32</name>
<script></script>
</card>
card_115819.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When color coding is used, ensure that each color represents only one category of displayed data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Color will prove the dominant coding dimension on a display. If several different categories of data are displayed in red, say, they will have an unwanted visual coherence which may hinder proper assimilation of information by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 7.6.1Smith Thomas 1964</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>433 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/31 Unique Assignment of Color Codes</span></text>
</content>
<name>2.6/31</name>
<script></script>
</card>
card_115680.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Make color coding redundant with some other display feature such as symbology; do not code only by color. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Displayed data should provide necessary information even when viewed on a monochromatic display terminal or hard-copy printout, or when viewed by a user with defective color vision. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/30 Redundant Color Coding</span></text>
</content>
<name>2.6/30</name>
<script></script>
</card>
card_115210.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Add color coding after displays have already been designed as effectively as possible in a monochrome format. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not use color coding in an attempt to compensate for poor display format. Redesign the display instead. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 7.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>431 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/29 Adding Color to Formatted Displays</span></text>
</content>
<name>2.6/29</name>
<script></script>
</card>
card_114990.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Employ color coding conservatively, using relatively few colors and only to designate critical categories of displayed data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Casual, arbitrary use of colors on every display may cause displays to appear "busy" or cluttered. Casual use of color will also reduce the likelihood that significant color coding on particular displays will be interpreted appropriately and quickly by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 7.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>430 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/28 Conservative Use of Color</span></text>
</content>
<name>2.6/28</name>
<script></script>
</card>
card_114894.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When selecting colors for coding discrete categories of data, ensure that those colors are easily discriminable. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The harder it is for a user to identify a displayed color, the less useful will be the color code. If many colors are used, colors will be closer in hue and harder to discriminate. If color coding is applied to symbols that subtend small visual angles, which makes color perception difficult, there will be a special need to limit the number of colors used. Varying saturation and intensity in addition to hue may increase the discriminability of colors. For instance, on a dark background a designer might select a saturated yellow but a desaturated red. Colors selected for coding should be tested with users to ensure that they are easily discriminable. Testing should be conducted under realistic conditions, since such factors as display type and ambient room lighting will affect color perception. If colors will be used for displaying text, care should be taken to ensure that colored letters are legible as well as discriminable. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">On a light background, a good choice of colors might be red, dark yellow, green, blue and black; on a dark background, good colors might be a somewhat desaturated red, green and blue, plus yellow and white. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>429 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/27 Easily Discriminable Colors</span></text>
</content>
<name>2.6/27</name>
<script></script>
</card>
card_114536.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must distinguish rapidly among several discrete categories of data, particularly when data items are dispersed on a display, consider using a unique color to display the data in each category. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Color is a good auxiliary code, where a multicolor display capability is available. A color code can be overlaid directly on alphanumerics and other symbols without significantly obscuring them. Color coding permits rapid scanning and perception of patterns and relationships among dispersed data items. Perhaps as many as 11 different colors might be reliably distinguished, or even more for trained observers. As a practical matter, however, it will prove safer to use no more than five different colors for category coding. With some display equipment now providing millions of different colors, designers may be tempted to exploit that capability by using many different colors for coding. The capability to display many colors may be useful for depicting complex objects, and for providing tonal codes to show the relative values of a single variable. However, such a capability is not useful for coding discrete categories, except that it may allow a designer to select more carefully the particular colors to be used as codes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Different colors might be used effectively in a situation display to distinguish friendly, unknown, and hostile aircraft tracks, or alternatively to distinguish among aircraft in different altitude zones. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 7.2Engel Granda 1975 § Table 1MIL-STD-1472C 1983 § 5.15.3.3.7Smith 1962bSmith 1963aSmith Thomas 1964Smith Farquhar Thomas 1965</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>428 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/26 Color Coding for Data Categories</span></text>
</content>
<name>2.6/26</name>
<script></script>
</card>
card_114289.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the relative rather than the absolute values of a variable are important, consider displaying gradual color changes as a tonal code to show the relative values of a single variable. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A gradual change in color might be achieved by varying saturation, starting with a saturated hue and gradually adding white. Or the change might be in intensity, starting with an intense hue and gradually adding black. Or the change might be in hue, moving gradually from red through orange, yellow, green, etc. People can easily make relative color comparisons when colors are displayed simultaneously. However, people find it more difficult to make absolute color judgments. Part of the problem is color naming. A particular blue-green hue might be named "green" by one person but "blue" by another. In the example above, a user could not be expected to associate any particular shade of blue with a specific ocean depth. Gradual color changes should not be used when absolute values are important, or to code data into discrete categories. As an example, in displaying revenues to determine the point at which a company becomes profitable, it would be more appropriate to use two distinctly different colors, such as black and red, with the color changing at the point of profitability. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In displaying ocean depth, a saturated blue might be used to show the deepest point, with gradually desaturated blues to show decreasing depth. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.8/7 Tonal Codes</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>427 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/25 Color Coding for Relative Values</span></text>
</content>
<name>2.6/25</name>
<script></script>
</card>
card_114105.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a capability for brightness inversion is available (so-called "reverse video"), where dark characters on a bright background can be changed under computer control to bright on dark, or vice versa, consider brightness inversion for highlighting critical items that require user attention. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Brightness inversion is obviously limited to use as a two-valued code, i.e., a displayed item is either shown with standard or inverted brightness. If brightness inversion is used for alerting purposes, as recommended here, it should be reserved consistently for that purpose, and not be used for general highlighting. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 3.3.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/7 Consistent Coding Across Displays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>426 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/24 Brightness Inversion</span></text>
</content>
<name>2.6/24</name>
<script></script>
</card>
card_113778.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider coding by differences in brightness for applications that only require discrimination between two categories of displayed items; i.e., treat brightness as a two-valued code, bright and dim. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Perhaps as many as four brightness levels might be used, but at some risk of reduced legibility for the dimmer items. It will be safer to reserve brightness as a two-valued code, particularly for displays whose overall intensity can be adjusted at the terminal by a user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A data form might display dim labels and bright data items, in order to facilitate data scanning. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.1.4 Table 1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/16 Distinctive Label Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>425 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/23 Limited Use of Brightness Coding</span></text>
</content>
<name>2.6/23</name>
<script></script>
</card>
card_113417.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For size coding, a larger symbol should be at least 1.5 times the height of the next smaller symbol. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An increase in symbol height must usually be accompanied by a proportional increase in width to preserve a constant aspect ratio and so facilitate symbol recognition. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.3.6</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>424 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/22 Adequate Differences in Size</span></text>
</content>
<name>2.6/22</name>
<script></script>
</card>
card_113255.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider size coding, i.e., varying the size of displayed alphanumerics and other symbols, only for applications where displays are not crowded. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Perhaps as many as five sizes might be used for data categorization, but two or three will probably prove the practical limit. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 1MIL-STD-1472C 1983 § 5.15.3.3.6</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>423 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/21 Limited Use of Size Coding</span></text>
</content>
<name>2.6/21</name>
<script></script>
</card>
card_113101.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider using codes with lines of varying direction for applications involving spatial categorization in two dimensions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users can make fairly accurate estimates of angles for lines displayed at ten-degree intervals. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The angle of a displayed vector might be used to indicate direction, i.e., heading or bearing. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Smith 1962a</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.2 Direction Designation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>422 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/20 Coding by Line Direction</span></text>
</content>
<name>2.6/20</name>
<script></script>
</card>
card_112740.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider using codes with lines of varying length for applications involving spatial categorization in a single dimension. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Perhaps four lengths can be reliably distinguished in practical use. Long lines will add clutter to a display, but may be useful in special applications. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The length of a displayed vector might be used to indicate speed. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>421 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/19 Coding by Line Length</span></text>
</content>
<name>2.6/19</name>
<script></script>
</card>
card_112502.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a line is added simply to mark or emphasize a displayed item, place it under the designated item. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A consistent convention is needed to prevent ambiguity in the coding of vertically arrayed items. For words composed from the Roman alphabet, underlining probably detracts from legibility less than would "overlining". </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.3.5</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>420 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/18 Underlining for Emphasis</span></text>
</content>
<name>2.6/18</name>
<script></script>
</card>
card_112323.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For graphic displays, consider using auxiliary methods of line coding, including variation in line type (e.g., solid, dashed, dotted) and line width ("boldness"). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Perhaps three or four line types might be readily distinguished, and two or three line widths. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.3/6 Line Coding to Distinguish Curves</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>419 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/17 Line Coding</span></text>
</content>
<name>2.6/17</name>
<script></script>
</card>
card_112116.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When shape coding is used, assign codes based on established standards or conventional meanings. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Although shape codes can often be mnemonic in form, their interpretation will generally rely on learned association as well as immediate perception. Existing user standards must be taken into account by the display designer. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A number of international, national, and organizational standards for shape coding exist, and those should be followed where they apply. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.3.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/7 Consistent Coding Across Displays4.0/13 Consistent Coding Conventions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>418 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/16 Establishing Standards for Shape Coding</span></text>
</content>
<name>2.6/16</name>
<script></script>
</card>
card_111832.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider coding with geometric shapes to help users discriminate different categories of data on graphic displays. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Approximately 15 different shapes can be distinguished readily. If that "alphabet" is too small, it may be possible to use component shapes in combination, as in some military symbol codes. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>417 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/15 Shape Coding</span></text>
</content>
<name>2.6/15</name>
<script></script>
</card>
card_111542.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a special symbol is used to mark a word, separate the symbol from the beginning of the word by a space. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A symbol immediately adjacent to the beginning of a word will impair legibility. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Noyes 1980</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>416 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/14 Markers Close to Words Marked</span></text>
</content>
<name>2.6/14</name>
<script></script>
</card>
card_111210.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When using special symbols to signal critical conditions, use them only for that purpose. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/7 Consistent Coding Across Displays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>415 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/13 Consistent Use of Special Symbols</span></text>
</content>
<name>2.6/13</name>
<script></script>
</card>
card_110998.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider using special symbols, such as asterisks, arrows, etc., to draw attention to selected items in alphanumeric displays. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.3/19 Alarm Coding</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>414 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/12 Special Symbols</span></text>
</content>
<name>2.6/12</name>
<script></script>
</card>
card_110632.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When arbitrary codes must be remembered by the user, ensure that they are no longer than four or five characters. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When a code is meaningful, such as a mnemonic abbreviation or a word, it can be longer. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When codes combine both letters and numbers, group letters together and numbers together rather than interspersing letters with numbers. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Unfortunately, there are common instances in which this practice has not been followed, such as the coding of British and Canadian postal zones. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Letter-letter-number ("HW5") will be read and remembered somewhat more accurately than letter-number-letter ("H5W"). </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For alphabetic codes display all letters consistently either in upper case or in lower case. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For data display, upper case labels may be somewhat more legible. For data entry, computer logic should not distinguish between upper and lower case codes, because users find it hard to remember any such distinction. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.3.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/27 Upper and Lower Case Equivalent</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>411 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/9 Consistent Case in Alphabetic Coding</span></text>
</content>
<name>2.6/9</name>
<script></script>
</card>
card_109941.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider alphanumeric characters for auxiliary coding in display applications such as graphics where the basic data presentation is not already alphanumeric. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Select alphanumeric codes that are visually distinct for visual displays, and phonetically distinct for auditory displays (or in any application where displayed codes must be spoken). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/18 Distinctive Abbreviation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>410 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/8 Alphanumeric Coding</span></text>
</content>
<name>2.6/8</name>
<script></script>
</card>
card_109593.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Assign consistent meanings to symbols and other codes, from one display to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When coding is not consistent, the user's task of display interpretation may be made more difficult than if no auxiliary coding were used at all. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When codes are assigned special meaning in a display, provide a definition at the bottom of the display that replicates the code being defined. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The legend on a map is a common example. For a color code each definition should be displayed in its appropriate color, as </span><span class="style8">| RED = hostile | </span><span class="style1">displayed in red. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 7.6.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/21 Definition of Display Codes</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>408 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/6 Definition of Display Codes</span></text>
</content>
<name>2.6/6</name>
<script></script>
</card>
card_109257.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt codes for display (and entry) that conform with accepted abbreviations and general user expectations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If in doubt, an interface designer can survey prospective users to determine just what their expectations may be. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Use M for "male", F for "female", rather than arbitrary digits 1 and 2. In color coding, use red for danger. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/32 Conventional Assignment of Color Codes4.0/14 Familiar Coding Conventions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>407 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/5 Familiar Coding Conventions</span></text>
</content>
<name>2.6/5</name>
<script></script>
</card>
card_109042.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt meaningful or familiar codes, rather than arbitrary codes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An arbitrary code, such as a Social Security Number, may eventually become familiar through frequent use. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A three-letter mnemonic code (DIR = directory) is easier to remember than a three-digit numeric code. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide display coding in applications where a user must distinguish rapidly among different categories of displayed data, particularly when those data are distributed in an irregular way on the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>405 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/3 Coding by Data Category</span></text>
</content>
<name>2.6/3</name>
<script></script>
</card>
card_108450.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If highlighting is used to emphasize important display items, remove such highlighting when it no longer has meaning. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If highlighting identifies an error, remove that highlighting when the error is corrected. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>404 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/2 Removing Highlighting</span></text>
</content>
<name>2.6/2</name>
<script></script>
</card>
card_108164.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide distinctive coding to highlight important display items requiring user attention, particularly when those items are displayed infrequently. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">"Highlight" is used here in its general sense, meaning to emphasize or make prominent, and is not restricted to any particular method of display coding such as brightening or inverse video. Highlighting is most effective when used sparingly, adding emphasis to a display which is relatively uniform in appearance except for just a few highlighted items. For some purposes position coding, i.e., displaying important items consistently in a particular location, might be a sufficient means of highlighting, as when an error message appears in a space otherwise left blank. But auxiliary codes may still be needed to highlight important items, even if they are positioned consistently. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Such items might include recently changed data, or discrepant data exceeding acceptable limits, or data failing to meet some other defined criteria. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.1.3 2.3.12MIL-STD-1472C 1983 § 5.15.3.3.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>403 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.6 Coding</span><span class="style21">2.6/1 Highlighting Critical Data</span></text>
</content>
<name>2.6/1</name>
<script></script>
</card>
card_107929.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When there is no appropriate logic for grouping data by sequence, function, frequency or importance, adopt some other principle such as alphabetical or chronological grouping. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/23 Logical List Ordering</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>402 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/18 Data Grouped Alphabetically or Chronologically</span></text>
</content>
<name>2.5/18</name>
<script></script>
</card>
card_107768.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where some data items are used more frequently than others, consider grouping those items at the top of the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Principles of data grouping also apply to the display/listing of control options. These recommendations for data grouping in display formatting follow familiar human engineering principles for display/control layout in equipment design. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.3/21 Logical Ordering of Menu Options</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>401 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/17 Data Grouped by Frequency</span></text>
</content>
<name>2.5/17</name>
<script></script>
</card>
card_107413.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where some displayed data items are particularly important, i.e., provide significant information and/or require immediate user response, consider grouping those items at the top of the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.2Tullis 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>400 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/16 Data Grouped by Importance</span></text>
</content>
<name>2.5/16</name>
<script></script>
</card>
card_107236.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where sets of data are associated with particular questions or related to particular functions, consider grouping each set together to help illustrate those functional relationships. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.2Tullis 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>399 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/15 Data Grouped by Function</span></text>
</content>
<name>2.5/15</name>
<script></script>
</card>
card_106819.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where displayed data are used in some spatial or temporal order, consider grouping those data by sequence of use to preserve that order. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Data in an electronic display should match the order of items in an associated paper data form. </span></text>
<text>1.4/25 Form Compatible with Source Documents1.4/27 Data Items in Logical Order2.4.7/5 Conventional Path Orientation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>398 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/14 Data Grouped by Sequence of Use</span></text>
</content>
<name>2.5/14</name>
<script></script>
</card>
card_106695.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If users must analyze sets of data to discern similarities, differences, trends, and relationships, structure the display format so that the data are consistently grouped. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Cost Output | | Actual Predicted Actual Predicted | | | | 947 901 83 82 | | 721 777 57 54 | | 475 471 91 95 | </span><span class="style1">(Bad) </span><span class="style8">| Cost Output | | Actual Predicted Predicted Actual | | | | 947 901 82 83 | | 721 777 54 57 | | 475 471 95 91 | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.6Tullis 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>397 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/13 Grouping for Data Comparison</span></text>
</content>
<name>2.5/13</name>
<script></script>
</card>
card_106336.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that displays are formatted to group data items on the basis of some logical principle, considering trade-offs derived from task analysis. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>396 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/12 Logical Data Organization</span></text>
</content>
<name>2.5/12</name>
<script></script>
</card>
card_106129.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Reserve the last several lines at the bottom of every display for status and error messages, prompts, and command entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Assuming that the display is mounted physically above the keyboard, which is the customary placement, a user can look back and forth from keyboard to display more easily when prompts and command entry area are at the bottom of the display. As a corollary to this recommendation, when separate command sets are associated with different display windows, such as options for display control (size of the window, positioning, etc.), those should be shown at the bottom of each window. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Begin every display at the top with a title or header, describing briefly the contents or purpose of the display; leave at least one blank line between the title and the body of the display. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a display window must be used for data scanning, ensure that the window can display more than one line of data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Elkerton etal 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>393 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/9 Adequate Window Size</span></text>
</content>
<name>2.5/9</name>
<script></script>
</card>
card_105410.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the need to view several different kinds of data jointly cannot be determined in advance, allow a user to define and select separate data windows that will share a single display frame. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Depending upon user needs (and system capability), data windows might appear simultaneously as segments of a joint display, might be overlaid in varying degrees so as to obscure one another, or might be displayed sequentially at the user's option. In the latter condition, multiple display windows will differ little from multiple display pages, except perhaps in speed of sequential access. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.5/3 User-Specified Windows</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>392 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/8 User-Defined Data Windows</span></text>
</content>
<name>2.5/8</name>
<script></script>
</card>
card_105067.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When coherent display is required to aid user perception of relations among data sets, provide those data in an integrated display rather than partitioning them into separate windows. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.2/1 Integrated Display</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>391 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/7 Integrated Display</span></text>
</content>
<name>2.5/7</name>
<script></script>
</card>
card_104822.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In a multipage display label each page to show its relation to the others. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.2/5 Annotating Display of Continued Data2.7.2/6 Numbering Display Pages4.2/7 Identifying Multipage Displays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>390 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/6 Page Labeling</span></text>
</content>
<name>2.5/6</name>
<script></script>
</card>
card_104511.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When partitioning displays into multiple pages, take into account the type of data, and display functionally related data items together on one page. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation is easily followed for text displays, involving primarily the elimination of "widows", considerate placement of illustrations, etc. For displayed data forms and tables, data grouping and continuation of headers must be considered. The partitioning of graphics displays may require radical redesign. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>389 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/5 Related Data on Same Page</span></text>
</content>
<name>2.5/5</name>
<script></script>
</card>
card_104263.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a display contains too much data for presentation in a single frame, partition the data into separately displayable pages. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">And provide convenient control procedures to allow users to move easily from one page to another. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Use blank space to structure a display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Closely packed data are difficult to locate and difficult to read. Thus blank space can be used to advantage to separate different groups of data. Related data items within a group, however, should be displayed close enough to minimize eye movement time in scanning those data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tullis 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>387 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/3 Spacing to Structure Displays</span></text>
</content>
<name>2.5/3</name>
<script></script>
</card>
card_103829.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Make the different elements of a display format distinctive from one another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Different display areas ("windows") can be separated by spacing (where space permits); outlining can also be used to separate different areas, so that displayed data, control options, instructions, etc., are distinct from each other. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3MIL-STD-1472C 1983 § 5.15.3.1.5Stewart 1980</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/8 Distinctive Display of Control Information4.0/8 Distinctive Format for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>386 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/2 Distinctive Display Elements</span></text>
</content>
<name>2.5/2</name>
<script></script>
</card>
card_103459.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt a consistent organization for the location of various display features from one display to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The objective is to develop display formats that are consistent with accepted usage and existing user habits. Consistent display formats will help establish and preserve user orientation. There is no fixed display format that is optimum for all data handling applications, since applications will vary in their requirements. However, once a suitable format has been devised, it should be maintained as a pattern to ensure consistent design of other displays. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">It might be desirable to change display formats in some distinctive way to help a user distinguish one task or activity from another, but the displays of any particular type should still be formatted consistently among themselves. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">One location might be used consistently for a display title, another area might be reserved for data output by the computer, and other areas dedicated to display of control options, instructions, error messages, and user command entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.1 1.8.5Engel Granda 1975 § 2.2.5 2.3 2.3.3MIL-STD-1472C 1983 § 5.15.3.2.1 5.15.3.3.4Foley Van Dam 1982Stewart 1980</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>385 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.5 Format</span><span class="style21">2.5/1 Consistent Format</span></text>
</content>
<name>2.5/1</name>
<script></script>
</card>
card_103241.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic data are changing and displays are automatically updated, provide some stable display elements, e.g., coordinates, geographic boundaries, etc. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Stable display elements provide a frame of reference to help users assimilate and interpret data changes. Moving data may overlay and temporarily obscure other display elements, such as fixed background data. When that happens, the display update logic must determine which data categories have priority on the display and which may be obscured by others, and should restore the obscured elements when the overlaid data moves away, and should further ensure that no data are erased from the display in the process of obscuring and restoring data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For vehicular control, a common display convention is to depict a moving element (aircraft) against a fixed background (horizon). </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.3/1 Automatic Display Update</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>384 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/18 Stable Reference for Changing Data</span></text>
</content>
<name>2.4.8/18</name>
<script></script>
</card>
card_102996.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If the particular data categories required at different stages in a user's job cannot be exactly predicted, allow the user to select the categories needed for any information handling task. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation does not lessen the designer's responsibility for determining user needs. Where user information requirements can be defined, displays should be designed to provide necessary data. User selection from available data categories may represent desirable flexibility to meet changing task requirements. However, there is a risk of "data indigestion" if a user selects the wrong categories or too many categories. Categories of selectable data might include relatively stable elements (e.g., defined flight paths, zones of radar coverage, etc.) as well as the variable elements that represent changing data (e.g., aircraft tracks). If auxiliary coding is adopted for different data categories, such as shape coding of symbols, code values should be chosen to be distinctive for any likely combination of displayed categories. Users should be provided a ready reminder of what data categories are available, and an easy means of selecting (or suppressing) displayed categories. This implies category selection by menu or function keys. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In monitoring aircraft separation for collision avoidance, a user might choose to display selectively the aircraft tracks within a particular altitude zone. To help identify an unrecognized aircraft track, a user might choose to add flight plan data temporarily to an air traffic display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.1/5 Selectable Data Categories</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>383 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/17 Selectable Data Categories</span></text>
</content>
<name>2.4.8/17</name>
<script></script>
</card>
card_102784.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When changes in mapped data are significant for a user's task, include auxiliary graphic elements to indicate those changes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In dynamic maps, i.e., situation displays, data changes involving movement can be shown directly. On static displays, arrows can be added to indicate the direction of movement of mapped elements. Where movement over an extended area must be represented, as in showing weather fronts, directional "pips" can be added to displayed contour lines. Some designers recommend that such pips should be displayed one to two times as large as alphanumeric characters, and that pip spacing should be five to ten times the pip width. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Auxiliary coding might be needed to indicate the movement of storm fronts on a weather map. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/20 Coding by Line Direction2.7.3/4 Visual Integration of Changing Graphics</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>382 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/16 Indicating Data Change</span></text>
</content>
<name>2.4.8/16</name>
<script></script>
</card>
card_102600.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When it is necessary to show the geographic location of changing events, which is often the case for monitoring real situations, combine event data with a map background. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A display for air traffic control might superimpose aircraft tracks on a background of geographic coordinates, with supplementary annotation and/or coding to indicate track identification, speed, heading, altitude, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>381 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/15 Situation Displays</span></text>
</content>
<name>2.4.8/15</name>
<script></script>
</card>
card_102217.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where the geographic distribution of nongeographic data must be displayed, consider adding other graphic elements to a map for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Alphanumeric characters might be added to a map to show data, but those will not aid a direct visual comparison across areas in the same way that graphic symbols can do. Moreover alphanumeric data may be confused with labels and other kinds of annotation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A symbol might be displayed in different sizes to indicate a particular measure in different localities, such as average population age, or average annual rainfall, or incidence of a particular disease. Small stacked bars might be superimposed on the different areas of a map to indicate the local distribution of some data measure, such as population distribution by age, education, or income. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>380 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/14 Mapping Nongeographic Data</span></text>
</content>
<name>2.4.8/14</name>
<script></script>
</card>
card_102027.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the use of mapped data may be complex, provide computer aids for data analysis. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In topographic analysis, computers might analyze contour data at different sites to calculate slopes and sun exposure for land use planning, or might calculate sight angles to determine radar coverage from different locations, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>379 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/13 Aids for Analyzing Maps</span></text>
</content>
<name>2.4.8/13</name>
<script></script>
</card>
card_101717.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must judge distances accurately on a map or other graphic display, provide computer aids for that judgment. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some designers display for this purpose a movable grid whose scale is controlled automatically by the computer depending upon current map expansion. Some designers have suggested that the grid might consist of a vertical and a horizontal line displayed across a series of concentric range rings. It might be more helpful to display a scaled line (ruler) that a user could move to intercept any two displayed points directly. For exact measurement, it might be better to allow a user to select (point at) any two points and have the computer "read-out" their separation distance directly. The same technique might be used to determine the direction (bearing) between two points. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>378 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/12 Aiding Distance Judgments</span></text>
</content>
<name>2.4.8/12</name>
<script></script>
</card>
card_101331.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user pans over an extended display in order to view different sections, provide some graphic indicator of the position in the overall display of the visible section. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">While panning across a map, moving from one section to another, a user may lose track of what is being displayed, and be uncertain how to move in order to see some other area of interest. An indicator of current position will help maintain user orientation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a corner of a panned display, the computer might show a rectangle representing the overall display, in which a smaller rectangle is placed to indicate the position and extent of the currently visible portion of that display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/17 Show Overview Position of Visible Section2.7.2/15 Show Overview Position of Visible Section</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>377 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/11 Show Overview Position of Visible Section</span></text>
</content>
<name>2.4.8/11</name>
<script></script>
</card>
card_100936.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a map exceeds the capacity of a single display frame, in terms of the required extent and detail of coverage, consider providing users a capability to pan the display frame over the mapped data in order to examine different areas of current interest. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">General guidelines for viewing different parts of an extended display by paging or panning/scrolling are considered elsewhere under the topic of display framing. Panning will permit users to move continuously over a map in any desired direction, without encountering any internal boundaries imposed by predefined display framing. An alternative approach might be to define various sections of a large map and link those sections by the same techniques used for linking sections of a large diagram. One risk in that approach is that an area of interest might be at a boundary where none of the sectional maps provide adequate coverage. Thus some degree of overlapped coverage is probably needed at the boundaries of displayed map sections. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.6/3 Linking Sectional Diagrams2.7.2/12 Panning for Flexible Display Framing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>376 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/10 Panning for Flexible Display Framing</span></text>
</content>
<name>2.4.8/10</name>
<script></script>
</card>
card_100710.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If one area in a map represents data of particular significance, implying a special need for user attention, highlight that area. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">On a weather map, special area coding might be used to indicate severe storm conditions. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/6 Highlighting Critical Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>375 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/9 Highlighting</span></text>
</content>
<name>2.4.8/9</name>
<script></script>
</card>
card_100492.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where different areas of a map are coded by texture patterns or tonal variation, order the assigned code values so that the darkest and lightest shades correspond to the extreme values of the coded variable. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Orderly assignment of code values will help users perceive and remember the categories represented by the code. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For indicating the height of mapped terrain, dark shades might be used for high elevations and light shades for low. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>374 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/8 Ordered Coding</span></text>
</content>
<name>2.4.8/8</name>
<script></script>
</card>
card_100316.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where users must make relative judgments for different colored areas of a display, consider employing tonal codes (different shades of one color) rather than spectral codes (different colors). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation represents an exception to other guidelines advocating distinctive code values. Coding by tonal variation should be considered only for applications where perception of relative differences along a single dimension is more important than perception of absolute values. People can order categories along a continuous dimension to match tonal variations in one color, whereas people do not have a natural means of ordering different colors. This recommendation is based on research with layer tints on printed displays. Some testing may be required to determine whether a particular electronic display permits effective variation in color tones. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For reading topographic maps, tonal variation might be used to show the relative height of displayed areas, perhaps with darker hues used to code greater heights. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Phillips 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/24 Brightness Inversion</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>373 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/7 Tonal Codes</span></text>
</content>
<name>2.4.8/7</name>
<script></script>
</card>
card_100052.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When different areas of a map must be defined, or when the geographic distribution of a particular variable must be indicated, consider the use of texture patterns or color or tonal codes for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications it may be desirable to limit area coding to one variable in order to assure effective information assimilation, in which case a designer should select that variable which is most significant. Another approach might be to allow a user to specify which variable will be coded on a map and to change that selection at will depending upon current task requirements. In some special applications, however, it may be feasible to superimpose several kinds of area coding to permit multivariate data analysis by skilled users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Coding might help define different areas of interest, such as the Eastern, Central, Mountain and Pacific time zones on a map of the United States, or perhaps areas of current rainfall on a weather map. Area coding might be used to indicate a geographic variable such as elevation or a demographic variable such as population. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6 Coding</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>372 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/6 Area Coding</span></text>
</content>
<name>2.4.8/6</name>
<script></script>
</card>
card_99658.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Position labels on a map consistently in relation to the displayed features they designate. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As a practical matter, map displays can get very crowded. It may not always prove feasible to maintain a consistent placement for labels, with the result that designers will be tempted to put labels wherever they will fit. In such a crowded display, labels may obscure map features, and vice versa. Locating and reading labels will be slowed, particularly when map features are displayed closely adjacent to the beginning of labels. Under these circumstances, some other approach to map labeling should be considered to avoid crowding. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The names of cities and towns might always be placed immediately above the corresponding symbols showing their locations. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Noyes 1980</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>371 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/5 Consistent Positioning of Labels</span></text>
</content>
<name>2.4.8/5</name>
<script></script>
</card>
card_99422.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Label significant features of a map directly in the display, when that can be done without cluttering the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When labeling and other desired annotation are too extensive to incorporate in the map itself, that material might be shown in some separate, peripheral area of the display. In that case, auxiliary coding might be used to link annotation with associated map features, e.g., by matching symbol codes. An alternative to fixed labeling would be to permit user interaction with computer-generated graphic displays. If a user selected a mapped point, a label might be temporarily displayed. If a user selected a marginal label, its associated map location might be highlighted. With interactive graphics, it may be possible to design maps with hierarchic levels of portrayed detail and labeling, so that a user can "zoom in" to examine an area in greater detail or "zoom out" for an aggregated overview. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/10 Consistent Annotation Format2.4/11 Normal Orientation for Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>370 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/4 Labeling Maps</span></text>
</content>
<name>2.4.8/4</name>
<script></script>
</card>
card_99156.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When maps represent large geographic areas, adopt a consistent method of projecting the earth's curvature on the flat display surface. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For large areas, any method of projection will introduce some distortion of apparent distances in the display. The projection used should be one which minimizes the practical effects of that distortion for the application at hand. If a selected method of map projection is used consistently, viewers can learn to compensate in some degree for the distortion it introduces. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hopkin Taylor 1979</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>369 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/3 Consistent Projection</span></text>
</content>
<name>2.4.8/3</name>
<script></script>
</card>
card_98992.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When several different maps will be displayed, adopt a consistent orientation so that the top of each map will always represent the same direction. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In common use, most maps are oriented so that North is upward. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>368 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/2 Consistent Orientation</span></text>
</content>
<name>2.4.8/2</name>
<script></script>
</card>
card_98661.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide maps to display geographic data, i.e., direction and distance relations among physical locations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here the term "map" refers to the display of relatively stable geographic data, or the display of slowly changing data such as weather. When mapped data change more quickly, as in the display of aircraft tracks for air traffic control, those diagrams are called "situation displays". Design recommendations for maps will generally pertain also to situation displays. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.8/15 Situation Displays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>367 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.8 Graphics - Maps and Situation Displays</span><span class="style21">2.4.8/1 Maps</span></text>
</content>
<name>2.4.8/1</name>
<script></script>
</card>
card_98438.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose some consistent format for wording the options displayed at the decision points in a flowchart. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sometimes it may not be possible to use a consistent format for displaying options. However, the more consistent a flowchart can be made in format and wording, the easier it will be to understand and use. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Decision options might be worded as questions, such as </span><span class="style8">| Will this car be driven more than 100 miles a week? |</span><span class="style1"> or worded as statements listing options, such as </span><span class="style8">| Car will be driven: | | h = more than 50 miles per week | | a = 25 to 50 miles per week | | l = less than 25 miles per week | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a flowchart is designed so that a user must make decisions at various steps, display the available options in some consistent order from step to step. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The point here is that for options which have no inherently logical order, some order should be consistently imposed. Consistent ordering will permit a user to review a flowchart more quickly. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">"Yes" might always be on the left and "no" on the right. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>365 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/11 Consistent Ordering of Options</span></text>
</content>
<name>2.4.7/11</name>
<script></script>
</card>
card_97909.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a flowchart is designed so that a user must make decisions at various steps, display the available options in some logical order. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The ordering of options should not be determined merely by the amount of space that is conveniently available to display them. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Temperature at inlet valve (0F): | | h = more than 400 | | a = 300-400 | | l = less than 300 | </span><span class="style1">(Bad) </span><span class="style8">| Temperature at inlet valve (0F): | | a = 300-400 | | h = more than 400 | | l = less than 300 | </span><span class="style1">If options represent stages of a process, those stages should be listed in the order in which they would actually occur. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>364 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/10 Logical Ordering of Options</span></text>
</content>
<name>2.4.7/10</name>
<script></script>
</card>
card_97741.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a flowchart is designed so that a user must make decisions at various steps, require only a single decision at each step, rather than combining decisions to reduce flowchart size. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Combining decisions in a single step, such as asking </span><span class="style8">| Does the temperature exceed 500 0C and the pressure | | exceed 2250 psi? | </span><span class="style1">may save space. But such a choice might confuse a user who will be uncertain what path to follow if a situation meets only one of the combined criteria, i.e., in this example, if the temperature is above 500 but the pressure is below 2250. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>363 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/9 Single Decision at Each Step</span></text>
</content>
<name>2.4.7/9</name>
<script></script>
</card>
card_97338.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If one element in a flowchart represents data of particular significance, implying a special need for user attention, highlight that element. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Color coding may be particularly appropriate in flowcharts, because of the effective primacy of color for guiding the visual scanning required to trace paths. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Line coding by color or bolding might be used to highlight displayed paths, and/or the boxes or other graphic elements representing displayed states. Highlighting might be used to distinguish scheduled vs. actual accomplishment, emphasizing critical time delays, cost overruns, or other discrepant conditions. As a cautionary example, the flowchart instructions for cleaning an electric lawnmower might highlight a box which says "unplug it before touching the blade". </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In flow charts and other graphics displays, use arrows in a conventional fashion to indicate directional relations in the sequential links between various elements. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>361 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/7 Conventional Use of Arrows</span></text>
</content>
<name>2.4.7/7</name>
<script></script>
</card>
card_96875.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When it is necessary to distinguish different types of flowchart elements, adopt a consistent coding scheme for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Flowchart coding within any system should conform to established conventions and user expectations, with some flexibility to meet changing user requirements. For some applications, such as the operational sequence diagrams noted in the example above, flowcharts may have to meet normative standards established across systems. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Shape coding of "boxes" in a flowchart is commonly used to indicate the different user actions in an operational sequence diagram that displays the results of task analysis. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Geer 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>360 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/6 Consistent Coding of Elements</span></text>
</content>
<name>2.4.7/6</name>
<script></script>
</card>
card_96521.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design flowcharts so that the path of the logical sequence is consistent with familiar orientation conventions, i.e., from left to right (for users accustomed to reading English) and from top to bottom, or perhaps clockwise. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When there is no inherently logical order to the steps in a flowchart, order them to minimize flowchart size, i.e., to minimize average path length. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Flowchart size can sometimes be reduced by placing first those steps that represent binary decisions. When all decision options are not equally probable, consider minimizing the length of the most likely path, i.e., that most frequently followed, rather than minimizing the overall size of the flowchart. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>358 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/4 Ordering to Minimize Path Length</span></text>
</content>
<name>2.4.7/4</name>
<script></script>
</card>
card_96098.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design flowcharts so that their displayed steps follow some logical order. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When a flowchart displays some sequential process, then display the steps in the order of that sequence. When a flowchart is provided as a problem solving aid, then steps might be ordered by importance, where those decisions which will have the largest impact on the final problem solution are made first, or ordered by certainty, where decisions which can be made with the most certainty are made first. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>357 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/3 Logical Ordering of Steps</span></text>
</content>
<name>2.4.7/3</name>
<script></script>
</card>
card_95943.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider providing a flowchart to aid problem solving when a solution can be reached by answering a series of questions, and when no tradeoffs will be required. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A flowchart can add structure to complex problem solving by illustrating a set of discrete decision points. With such a flowchart, a user is given specific steps to follow in solving a problem, helping to ensure that all relevant factors are considered. For simple problems, however, a tabular or text format may be read more quickly than a flowchart. Flowcharts are not useful when a user must make tradeoffs. For example, if a user must evaluate alternative outcomes if s/he could invest more money or could accept lower quality, then using a flowchart would be cumbersome and time consuming. When a user must evaluate alternatives, a tabular format may be more efficient. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In process control, a flowchart might aid problem diagnosis when a user must determine the cause of abnormal conditions and take appropriate action. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>356 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/2 Flowcharts to Aid Problem Solving</span></text>
</content>
<name>2.4.7/2</name>
<script></script>
</card>
card_95719.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider flowcharts for schematic representation of sequence information, i.e., to display data that are logically related in terms of sequential processes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Flow charts are frequently used for process control, project scheduling, and other similar applications. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>355 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.7 Graphics - Flowcharts</span><span class="style21">2.4.7/1 Flowcharts</span></text>
</content>
<name>2.4.7/1</name>
<script></script>
</card>
card_95356.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users must analyze pictorial images in detail, provide appropriate computer aids for that purpose. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For examining displayed surfaces, it might be helpful to allow a user to specify/control the light source adopted for computer-generated images. For photo interpretation, computer processing can sometimes improve the visual quality of stored images, as by edge enhancement. For examining the component structure of a complex object, as for an assembly or maintenance task, it might be helpful to allow a user to "explode" an aggregate display into its several elements. For examining the internal structure of a depicted object, it might be helpful to allow a user to request auxiliary displays of specified cross-sections or transect diagrams. For more detailed structural analysis of depicted objects, it might be necessary to provide computer aids for calculating area, volume, center of gravity, modes of vibration, stresses, heat transfer, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>354 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.6 Graphics - Pictures and Diagrams</span><span class="style21">2.4.6/6 Aids for Pictorial Analysis</span></text>
</content>
<name>2.4.6/6</name>
<script></script>
</card>
card_95150.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In an application where a user must examine a depicted object from different viewpoints, allow the user to rotate its displayed image. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The axis of rotation will generally be the center of the depicted object. Where that is not the case, some indication of the rotation axis should be displayed. In some applications it might also help the user to display some explicit separate indication ("gnomon") of the degree of rotation and the current orientation of the depicted object. In applications where a user must make a detailed comparison of two (or more) displayed objects, it may be necessary to allow independent rotation, translation and superposition of their images. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982Foley Wallace Chan 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>353 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.6 Graphics - Pictures and Diagrams</span><span class="style21">2.4.6/5 Rotation</span></text>
</content>
<name>2.4.6/5</name>
<script></script>
</card>
card_94949.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a picture or diagram contains data of particular significance, implying a special need for user attention, highlight those data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Selected portions of pictures might be highlighted by adding a box outline to the display, or perhaps a blinking arrow; diagram elements might be highlighted by bolding or video reversal, or perhaps by color coding. Highlighting might be used to indicate a computer analysis of design deficiencies in a depicted object, or an assessment of damage when monitoring a system that has been degraded in some way. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When diagrammed data exceed the capacity of a single display frame and must be shown in separate sections, provide an overview for the diagram, a consistent notation to indicate the logical linking of its various sections, and an easy means for users to move from one section to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">General guidelines for linking sectional displays by paging/scrolling are considered elsewhere under the topic of display framing. The concern here is to establish a coherent structure to show logical relations among the separately displayed parts of a diagram. The solution may require internal notation and perhaps replication of some portions of the diagram from one section to another. An alternative approach might be to construct a hierarchic diagram with a zooming capability to show greater detail. That capability represents a potential advantage of computer-generated electronic displays over printed diagrams. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The sections of a diagram might be assigned letter codes, which could be shown in the overview and at any internal branch points, and which could be entered by a user to request the display of various sections. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/15 Zooming for Display Expansion2.7.2 Display Control Framing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>351 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.6 Graphics - Pictures and Diagrams</span><span class="style21">2.4.6/3 Linking Sectional Diagrams</span></text>
</content>
<name>2.4.6/3</name>
<script></script>
</card>
card_94284.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use diagrams to show spatial relations, with selective focus on the data specifically required by a user's task, in applications where a full pictorial rendering might be unnecessarily complicated. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Diagrams are here considered a special form of picture. Diagrams should be kept as simple as possible, omitting unnecessary data. A system diagram for a subway engineer would have to be quite complex, showing accurate distances and directions, and perhaps the relation between subway sections and surface streets, utility lines, etc. But a subway diagram intended for a tourist might display simply the connecting links between one station and another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Diagrams are used to support many applications, ranging from mechanical assembly/maintenance instruction to the representation of electronic circuitry, or floor plans, or organizational hierarchies. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/2 Only Necessary Data Displayed2.4/5 Only Necessary Information Displayed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>350 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.6 Graphics - Pictures and Diagrams</span><span class="style21">2.4.6/2 Diagrams</span></text>
</content>
<name>2.4.6/2</name>
<script></script>
</card>
card_94059.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use pictorial displays in applications where it is necessary to show accurately detailed representations of real or imaginary objects or processes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications it may be possible for a computer to synthesize pictorial displays from stored data. This is true in computer-aided design, where the computer must display a designed object that does not yet exist. For a map-reading task, a computer might synthesize perspective views of terrain from topographic data, where real images are not available. For some information-handling tasks the display of detailed images (photographs) will help users. In other instances, simplified line drawings may be more readily comprehended. Dynamic display of "moving pictures" can exploit various animation techniques to improve the pictorial representation of complex objects and processes. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Pictorial displays aid in the analysis of objects and events, as in the case of photo interpretation. Pictorial displays support a variety of computer-aided design applications, including the design of aircraft, artificial hearts, automobiles, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>349 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.6 Graphics - Pictures and Diagrams</span><span class="style21">2.4.6/1 Pictures</span></text>
</content>
<name>2.4.6/1</name>
<script></script>
</card>
card_93775.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a particular segment of a pie chart requires emphasis, highlight it by special hatching or shading and/or by "exploding" it, i.e., displacing it slightly from the remainder of the pie. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If pie charts are used, add numbers to their segment labels to indicate the percentage and/or absolute values represented in the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Because pie charts include no explicit reference scale or index, the only way they can convey numeric values accurately is through their labeling. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>347 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.5 Graphics - Pie Charts</span><span class="style21">2.4.5/3 Numeric Labels</span></text>
</content>
<name>2.4.5/3</name>
<script></script>
</card>
card_93335.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If pie charts are used, label the segments directly rather than by a separate legend, in a normal orientation for reading text. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/11 Normal Orientation for Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>346 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.5 Graphics - Pie Charts</span><span class="style21">2.4.5/2 Labeling Pie Charts</span></text>
</content>
<name>2.4.5/2</name>
<script></script>
</card>
card_93018.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider a pie chart only in special cases to show the relative distribution of data among categories, i.e., for displaying data that represent proportional parts of a whole; but note that a bar graph will permit more accurate interpretation for such applications. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">There are several significant limitations to a pie chart -- in itself it provides no means of absolute measurement, it cannot represent totals greater than 100 percent, and it can only represent a fixed point in time. Estimation of angular relations, as required in pie charts, is less accurate than estimation of linear extent. Pie charts may have artistic merit in some applications, but will not support accurate assimilation of data. If pie charts are used, some designers recommend that partitioning be limited to five segments or less. Multiple pie charts will not permit accurate comparison of different totals, although different-sized pies can be used to indicate gross differences. Stacked bar graphs will prove more effective for this purpose and should be used when it is necessary to show proportions of different totals. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cleveland 1985</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.4/9 Stacked or Segmented Bars</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>345 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.5 Graphics - Pie Charts</span><span class="style21">2.4.5/1 Restricted Use of Pie Charts</span></text>
</content>
<name>2.4.5/1</name>
<script></script>
</card>
card_92780.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider using iconic symbols of varying size (rather than simple bars) to represent quantitative values in bar graphs only in special cases when unambiguous icons can be provided and when no interpolation will be necessary. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In general, use of icons to represent quantitative information, such as when a silhouette of a person represents 1000 people in a graph, should be avoided. Icons are often ambiguous, and so must be explained somewhere on the figure. In addition, users will find it difficult to interpolate using icons. If a silhouetted person represents 1000 people, then how many people are represented by a silhouette showing just two legs? </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>344 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/11 Restricted Use of Icons</span></text>
</content>
<name>2.4.4/11</name>
<script></script>
</card>
card_92461.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In stacked bars, order the data categories within each bar in the same sequence, with the least variable categories displayed at the bottom and the most variable at the top. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In effect, a series of stacked bars is analogous to the stacked curves of a surface chart, and the same design considerations should apply. Some designers recommend displaying the largest values as the bottom segment. Whatever logic is chosen should be maintained consistently from one display to another. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.3/13 Ordering Data in Surface Charts</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>343 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/10 Ordering Data in Stacked Bars</span></text>
</content>
<name>2.4.4/10</name>
<script></script>
</card>
card_92406.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider stacked bars, in which differently coded segments are shown cumulatively within a bar, when both the total measures and the portions represented by the segments are of interest. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>342 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/9 Stacked or Segmented Bars</span></text>
</content>
<name>2.4.4/9</name>
<script></script>
</card>
card_91913.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When bars are displayed in pairs, label the bars in one pair directly to distinguish the two entities being compared, rather than displaying a separate legend. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Direct labeling of bars will permit efficient information assimilation by a user. If the user has to refer to a separately displayed legend, interpretation of the chart will be slower and more subject to error. It will probably be sufficient to label just one pair of bars rather than all of them. Labels should have a conventional orientation for reading text. In a dynamic display where bar length may change while being displayed, label position may have to change accordingly. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/11 Normal Orientation for Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>341 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/8 Labeling Paired Bars</span></text>
</content>
<name>2.4.4/8</name>
<script></script>
</card>
card_91821.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When paired measures from two data sets must be compared, consider displaying each pair as contiguous or (partially) overlapped bars. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Paired bars will permit a direct visual comparison by the user. When more than two data sets must be compared, a display of grouped bars will be less effective. As the number of matched items becomes larger, it might be better to display the data sets in separate bar graphs, or to allow users to select different sets of data for simultaneous display. In some applications, a good alternative might be to display directly the difference between paired measures. That is to say, a pair of bars showing income and expenses might be converted to a single bar showing the net difference: a "profit" bar might be displayed extending above a "break-even" index line, and a "loss" might be displayed descending below that line. In a dynamic display where bar length may change while being displayed, it will probably not be a good design choice to overlap the bars. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A common application of paired data is the display of planned versus actual quantities. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.3/11 Direct Display of Differences</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>340 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/7 Paired or Overlapped Bars</span></text>
</content>
<name>2.4.4/7</name>
<script></script>
</card>
card_91439.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In a simple bar graph, if one bar represents data of particular significance, highlight that bar. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If bar coding is already used for other purposes, such as to distinguish among different sets of grouped bars, then no additional highlighting code should be superimposed on the bars themselves; perhaps some other means of highlighting (e.g., an arrow) might be adopted. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If one bar represents critical/discrepant data, that bar might be displayed with different tonal coding, such as solid black rather than cross-hatched (or vice versa). </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When the extent of displayed bars must be compared with some critical value, include a reference index in the chart to aid that comparison. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Indexing may be complicated in situations where the displayed bars do not represent a common measure. In such a case, it might help to choose (or devise) an index scheme so that bar lengths will fall in the same zone under normal conditions, so that deviations in bar length will be readily noticed by users who must monitor changing data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A horizontal line might be an adequate reference index for a vertical bar graph. If bars are shown to monitor the pulse rates of patients under intensive care, then two reference lines might be displayed to define an acceptable zone. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/7 Reference Index or Baseline</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>338 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/5 Reference Index</span></text>
</content>
<name>2.4.4/5</name>
<script></script>
</card>
card_90982.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Space adjacent bars closely enough that a direct visual comparison can be made without eye movement. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In this regard, some designers recommend that the spacing between bars be less than the bar width. If there are a great many bars to be displayed, then spacing will produce an alternating pattern of bright and dark bands that could prove visually disturbing, particularly for viewers with epileptic vulnerability. In such a case it might be better to display a histogram with no spacing between bars. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>337 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/4 Bar Spacing</span></text>
</content>
<name>2.4.4/4</name>
<script></script>
</card>
card_90639.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In a related series of bar graphs, adopt a consistent orientation for bars displaying similar information, either vertical or horizontal. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent orientation will aid users in assimilating information from a series of bar graphs. Here the phrase "bar graph" is used to denote graphic displays in which bars extend either horizontally or vertically. Some designers distinguish between these two alternatives, calling displays with vertical bars "column charts". </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Vertical bars can be used to display frequency counts, size, cost, or a large variety of other measured attributes. If bar length is used to represent time duration, then it might be more appropriate to orient the bars horizontally, in accord with the general convention of plotting time on the horizontal axis of a graph. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>336 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/3 Consistent Orientation of Bars</span></text>
</content>
<name>2.4.4/3</name>
<script></script>
</card>
card_90539.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider histograms (step charts), bar graphs without spaces between the bars, when there are a great many entities or intervals to be plotted. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Histograms are often used to plot frequency data, i.e., the frequency of observations for each of many intervals scaled along the X-axis. For such applications, a histogram will avoid the "picket fence" appearance which might result from spaces between bars. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>335 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/2 Histograms (Step Charts)</span></text>
</content>
<name>2.4.4/2</name>
<script></script>
</card>
card_90256.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider bar graphs, where numeric quantities are represented by the linear extent of parallel bars, for comparing a single measure across a set of several entities or for a variable sampled at discrete intervals. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Displayed bars are usually shown extending from a common origin. For some applications, however, the bars might extend between separately plotted high- and low-points. Bars might be displayed, for example, to indicate the range of observed measures. The displayed linear extent of adjacent bars permits direct visual comparison of quantity, and thus effective assimilation of comparative data by users. The value of the bar graph format, as with other graphic displays, is to speed information assimilation by a user. In some applications, however, a user can scan displays in a leisurely way, as when reviewing printed output. In such cases, the data shown in a bar graph could often be presented more economically (i.e., more compactly) by a textual description or in a small table. For experienced users, the overall pattern of a bar graph may serve a diagnostic function beyond the comparison of individual bars. For example, if multiple bars show data from different components of a complex system, then users may learn characteristic "profiles" of the bars which indicate system status. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>334 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.4 Graphics - Bar Graphs</span><span class="style21">2.4.4/1 Bar Graphs</span></text>
</content>
<name>2.4.4/1</name>
<script></script>
</card>
card_89875.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider cumulative curves to show the current total at any point; but do not rely on cumulative curves to show effectively the amount of change at any point. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Cumulative curves tend to "wash out" local variations in the displayed data. The rate of change in incremental data can be estimated by judging the slope of a cumulative curve at any point, but that is hard to do. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>333 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/15 Cumulative Curves</span></text>
</content>
<name>2.4.3/15</name>
<script></script>
</card>
card_89838.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where space permits, label the different areas of surface charts directly within the textured or shaded bands. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>332 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/14 Labeling Surface Charts</span></text>
</content>
<name>2.4.3/14</name>
<script></script>
</card>
card_89405.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Order the data categories in a surface chart so that the least variable curves are displayed at the bottom and the most variable at the top. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In a surface chart, any irregularity in the bottom curve will "propagate" throughout the curves above it, which will make it difficult for a user to distinguish whether apparent irregularity in upper curves is real or merely a consequence of this method of presentation. Sometimes there are independent logical grounds for the ordering of data categories. If a surface chart constructed on a logical basis produces confusing irregularity of curves, then it might be better to display the data in some other graphic format. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.4/10 Ordering Data in Stacked Bars</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>331 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/13 Ordering Data in Surface Charts</span></text>
</content>
<name>2.4.3/13</name>
<script></script>
</card>
card_89098.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When curves represent all of the portions of a whole, consider using a surface chart in which curves are stacked above one another to display aggregated amounts, and the areas defined below the curves are textured or shaded. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The area texture or shading between curves has an implication of volume that is appropriate for many purposes. However, for curves that do not represent parts of a whole (e.g., a set of price indices), surface charts might have misleading implications and should not be used. Surface charts permit smooth, continuous display of data categories that might be represented in more discrete form by a set of segmented bars. Thus, recommendations for surface charts may be applied also to segmented bar charts. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Surface charts might be appropriate to display sales volume over time in different market areas, or for different products. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.4/9 Stacked or Segmented Bars</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>330 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/12 Surface Charts</span></text>
</content>
<name>2.4.3/12</name>
<script></script>
</card>
card_89066.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where users must evaluate the difference between two sets of data, plot that difference directly as a curve in its own right, rather than requiring users to compare visually the curves that represent the original data sets. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some designers recommend band charts, where two curves are plotted and the area between them is textured or shaded, for applications where the difference between curves is of interest, but where that difference must be interpreted in terms of the absolute values of the two variables. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If two curves represent income and expenses, then it might help to plot the difference between those curves to show profit (or loss). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cleveland 1985</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>329 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/11 Direct Display of Differences</span></text>
</content>
<name>2.4.3/11</name>
<script></script>
</card>
card_88651.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where curves represent cyclic data, consider extending the graph to repeat uncompleted portions of the displayed cycle. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The intent here is to allow users to scan any critical portion of the displayed cycle without having to return visually to the beginning of the plot. How much extension is desirable will depend on the particular application. In short, data that are used together should be displayed together. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A plot showing train arrival times at different stations should be extended beyond a 24-hour cycle as necessary to show the complete schedules of any trains en route at midnight. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>328 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/10 Repeating Display of Cyclic Data</span></text>
</content>
<name>2.4.3/10</name>
<script></script>
</card>
card_88559.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When curves must be compared with some critical value, include a reference index in the chart to aid that comparison. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In such cases, the index might be displayed as a horizontal or vertical line, or perhaps as a reference curve of some kind. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/7 Reference Index or Baseline</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>327 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/9 Reference Index</span></text>
</content>
<name>2.4.3/9</name>
<script></script>
</card>
card_88302.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When curves represent planned or projected or extrapolated data, show them consistently as broken (dashed or dotted) lines to distinguish them from solid curves representing actual data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A consistent convention in this regard will make charts easier to interpret. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>326 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/8 Broken Lines for Projected Curves</span></text>
</content>
<name>2.4.3/8</name>
<script></script>
</card>
card_87821.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When coding by line type in a series of displayed charts, use line codes consistently to represent corresponding data. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>325 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/7 Consistent Line Codes</span></text>
</content>
<name>2.4.3/7</name>
<script></script>
</card>
card_87724.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When multiple curves are displayed in a single graph, and particularly if those curves approach and/or intersect one another, provide line coding to distinguish one curve from another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Lines might also be coded by stroke width, including at least wide (bold) and narrow (light), but it is probably better to reserve that distinction for use in distinguishing data curves (bold) from background display of reference grids (light). In particular, do not use bold or heavy dots for coding, but reserve those for plotting data points. Aside from conventional means of display coding, it may be possible to provide aids that are more interactive. For example, the computer might highlight any particular curve selected by a user. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When one curve must be compared with a set of other curves, which need not themselves be distinguished, then it might help to display all the curves with the same line type and highlight the one curve that is intended to be distinctive. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Curves might be distinguished by different colors or different line types; commonly recommended line types include solid, dashed, dotted, and dot-dashed. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cleveland 1985</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/17 Line Coding</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>324 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/6 Line Coding to Distinguish Curves</span></text>
</content>
<name>2.4.3/6</name>
<script></script>
</card>
card_87525.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In charts displaying multiple curves, if one curve represents data of particular significance, highlight that curve. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If line coding is already used to distinguish among multiple curves, then the means of highlighting any particular curve should be selected so that it will not be confused with coding for visual separation. For example, if displayed curves are distinguished by line codes (solid, dashed, dotted, etc.), then one curve might be highlighted by displaying it in a different color. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If one curve represents critical/discrepant data, that curve might be displayed with a noticeably thicker line stroke or in a different color. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/5 Highlighting</span></text>
</content>
<name>2.4.3/5</name>
<script></script>
</card>
card_87251.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a legend must be displayed, order the codes in the legend to match the spatial order of their corresponding curves in the graph itself. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If legends are shown for a series of related graphs, then adopt some logical order consistently for all of those legends. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>322 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/4 Compatible Ordering in Legends</span></text>
</content>
<name>2.4.3/4</name>
<script></script>
</card>
card_86881.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When multiple curves are included in a single graph, each curve should be identified directly by an adjacent label, rather than by a separate legend. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Direct labeling will permit users to assimilate information more rapidly than displaying a separate legend. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Where displayed curves are too close for direct labeling, an acceptable alternative might be to distinguish the various curves in some way, perhaps by color coding or line coding, and identify their codes in a separate legend. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Milroy Poulton 1978</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/11 Normal Orientation for Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>321 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/3 Labeling Curves</span></text>
</content>
<name>2.4.3/3</name>
<script></script>
</card>
card_86743.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When several curves must each be compared with the others, display them in one combined graph. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The objective here is an integrated display that will provide a user with all needed information. On the other hand, as more curves are added to a graph the user's task of comparison will become more difficult. Some designers recommend that no more than four curves be displayed in a single graph. Certainly it is clear that some reasonable limit should be adopted. If one particular curve must be compared with each of several others, some designers recommend multiple charts in which each pairing is shown separately, rather than displaying all the curves in one single chart. When multiple charts are used for such a purpose, the same scale should be used in each of the charts. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.6.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.1/2 Consistent Scaling</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>320 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/2 Comparing Curves</span></text>
</content>
<name>2.4.3/2</name>
<script></script>
</card>
card_86356.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider curves (in which data relations are summarized by a smoothed line) or line graphs (in which plotted data points are connected by straight line segments) for displaying relations between two continuous variables, particularly for showing data changes over time. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Line graphs are regarded here merely as a special form of plotted curves, hence recommendations for displaying curves are intended to apply also to line graphs. Curves are generally superior to other graphic methods for speed and accuracy in interpreting data trends. Unlike printed graphs, computer-generated curves can show dynamic data change, as in oscilloscope displays. A curve implies a continuous function. Where that could be misleading, a better choice might be a bar graph composed of discrete display elements from one data point to the next. Sometimes curves may be combined with other graph types. For example, annual sales for the past several years might be displayed as a bar chart, followed by curves to indicate monthly sales during the current year. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Schutz 1961</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>319 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.3 Graphics - Curves and Line Graphs</span><span class="style21">2.4.3/1 Curves and Line Graphs</span></text>
</content>
<name>2.4.3/1</name>
<script></script>
</card>
card_86102.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When scatterplots are grouped in a single display to show relations among several variables, provide some interactive aid for analysis so that if a user selects a set of data in one plot then the corresponding data points in other plots will be highlighted. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Data selection might be accomplished by "brushing" a scatterplot with a superimposed box of controllable size to define the data set of interest. That technique can exploit the capabilities of interactive graphics to permit a range of data analysis not possible when using printed graphs. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cleveland 1985</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>318 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.2 Graphics - Scatterplots</span><span class="style21">2.4.2/4 Interactive Analysis of Grouped Scatterplots</span></text>
</content>
<name>2.4.2/4</name>
<script></script>
</card>
card_85850.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When relations among several variables must be examined, consider displaying an ordered group (matrix) of scatterplots, each showing the relation between just two variables. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The ordering of several scatterplots in a single display might help a user discern relations among interacting variables. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cleveland 1985</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>317 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.2 Graphics - Scatterplots</span><span class="style21">2.4.2/3 Grouping Scatterplots to Show Multiple Relations</span></text>
</content>
<name>2.4.2/3</name>
<script></script>
</card>
card_85731.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If some plotted points represent data of particular significance, highlight those points to make them visually distinctive from others. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Significant data points might be highlighted by bolding, color, blinking, shape coding, or other means, or might be designated by supplementary display annotation. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Consider scatterplots, in which data are plotted as points in a two-dimensional graph, to display how two variables are correlated or to show the distribution of points in space. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Curves can be superimposed on scatterplots to indicate computed data trends, correlations, or other derived statistical measures, thus combining two types of graphic display. Scatterplots, as the name implies, are sometimes used to show a dispersal intended to indicate non-correlation of variables. But scatterplots may not be convincing for that purpose, because users will often perceive or imagine patterns in scattered data points where none actually exist. Note that scatterplots cannot be shown effectively in most forms of three-dimensional spatial representation because of inherent display ambiguities. (Here the triangular grid might be considered an exception.) A third dimension might be represented by coding the symbols used to plot different data categories. If that is done, however, the visual correlation between any two variables in the scatterplot will be obscured. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A changing display of points representing radar data, such as those used for monitoring aircraft tracks, might be regarded as a dynamic scatterplot. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>315 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.2 Graphics - Scatterplots</span><span class="style21">2.4.2/1 Scatterplots</span></text>
</content>
<name>2.4.2/1</name>
<script></script>
</card>
card_85180.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider three-dimensional scaling, where a Z-axis is added to the display, only in special applications for experienced users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Showing a Z-axis on a display that is limited to two actual dimensions will confuse many users. If three-dimensional scaling is employed, adopt a consistent method of representation, e.g., isometric or orthographic projection, perspective drawing, or triangular coordinate grid. It is often possible in graphic display to show a third dimension through use of auxiliary coding -- e.g., color or shape coding, or supplementary annotation -- which may prove more effective than trying to represent a third spatial dimension pictorially. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>314 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/13 Restricted Use of Three-Dimensional Scaling</span></text>
</content>
<name>2.4.1/13</name>
<script></script>
</card>
card_84960.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When grid lines are displayed, ensure that they do not look like data and do not obscure data elements -- curves, bars, plotted points, etc. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Grid lines should be thinner than data curves, and should be invisible behind depicted objects and areas such as the bars on a bar chart. Note in particular that heavy vertical grid lines may conceal the height of plotted peaks. In this respect, electronic displays offer more flexibility than printed graphs. Grids can be displayed or suppressed by user selection. For reading the value of a particular data point, perhaps no grid is needed at all. A user might simply ask the computer to display the value of any selected point. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Where accuracy of reading graphic data is required, provide computer aids for exact interpolation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">It might suffice to allow users to request a fine grid as an optional display feature; or it might be better to display vertical and horizontal rules that a user could move to intersect the axes of a chart; or it might prove best simply to let a user point at any data item and have the computer label that item with a readout of its exact value(s). </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>312 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/11 Aids for Scale Interpolation</span></text>
</content>
<name>2.4.1/11</name>
<script></script>
</card>
card_84240.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If different variables on a single graph seem to require different scales, consider scaling them against a common baseline index, rather than showing multiple scales. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An indexed chart can permit comparisons among different variables when multiple scales would otherwise be needed. However, care should be taken in selecting an appropriate base period against which to index, in order to ensure that comparisons will not be biased. Index scaling may also be appropriate for showing the effect of a single variable (such as money) whose units of measurement change in real value with time. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Rather than showing sales in units and profits in dollars, both might be graphed in terms of percent change from a baseline period. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/7 Reference Index or Baseline</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>311 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/10 Scaling Against a Reference Index</span></text>
</content>
<name>2.4.1/10</name>
<script></script>
</card>
card_84157.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design graphs so that only a single scale is shown on each axis, rather than including different scales for different curves in the graph. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Single-scale graphs will generally permit more accurate reading than graphs displaying several scales. Many users will be confused by multiple-scale graphs and make errors when interpreting them. Moreover, by changing the relative scale factors of multiple-scale graphs it is possible to change radically their apparent meaning and bias interpretation by users. If multiple-scale graphs are used, an interactive display capability might aid interpretation, e.g., permitting a user to select any curve and have the computer highlight the corresponding scale for that curve. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For users experienced in data analysis, multiple-scale charts may prove an effective tool for comparing relative values of different variables. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>310 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/9 Single Scale Only</span></text>
</content>
<name>2.4.1/9</name>
<script></script>
</card>
card_83817.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When scaled data will contain extreme values, display duplicate axes, so that the X-axis appears at both the top and bottom, and the Y-axis at both the left and right sides of the graph. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Extreme data values may be located far from conventionally placed axes. When duplicate axes are displayed at the top and right side, users will find it easier to read the extreme values. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When data comparisons of interest fall within a limited range, consider constructing the scaled axis to emphasize that range, with a break in the displayed axis to indicate discontinuity with the scale origin. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Note, however, that a broken axis distorts the displayed amount in relation to a base value and so risks confusing users. In effect, a user will expect that a scale marked in regular intervals will continue in a consistent fashion. If an axis must be broken, label that break clearly, perhaps with some indicator that extends across the displayed graph. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Cleveland 1985Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>308 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/7 Restricted Use of Broken Axes</span></text>
</content>
<name>2.4.1/7</name>
<script></script>
</card>
card_83431.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users must compare aggregate quantities within a display, or within a series of displays, scaling of numeric data should begin with zero. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If for any reason the zero point is omitted, the display should include a clear indication of that omission. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>307 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/6 Numeric Scales Start at Zero</span></text>
</content>
<name>2.4.1/6</name>
<script></script>
</card>
card_83052.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Construct scales with tick marks at a standard interval of 1, 2, 5, or 10 (or their multiples by 10) for labeled divisions; intervening tick marks to aid visual interpolation should be consistent with the labeled scale interval. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users will find it difficult to interpret scales based on odd intervals, even if computers do not. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In special instances, the X-axis might be scaled in odd intervals to show customary divisions, such as the seven days in a week or the 12 months in a year. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, it is not acceptable to let the computer divide available scale space automatically if that results in a scale labeled in unfamiliar intervals such as 6 or 13. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>306 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/5 Scaling in Standard Intervals</span></text>
</content>
<name>2.4.1/5</name>
<script></script>
</card>
card_82735.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Employ a linear scale for displayed data, in preference to logarithmic or other non-linear methods of scaling. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Most users are more familiar with linear scales and will interpret linear scales more accurately than other methods of scaling. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">A logarithmic scale shows percentage change rather than arithmetic change; it may be appropriate for some special applications. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>305 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4.1 Graphics - Scaling</span><span class="style21">2.4.1/4 Linear Scaling</span></text>
</content>
<name>2.4.1/4</name>
<script></script>
</card>
card_82649.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Label each scale axis clearly with its description and measurement units, if any. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Labels should be displayed in conventional text orientation on both the X- and Y-axis for ease of reading. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Labels might include "Population in Thousands", "Price in $1000", "Percent", "Fiscal Year", etc. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If users must compare graphic data across a series of charts, use the same scale for each chart. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users will find it difficult to compare data sets that are scaled differently. Moreover, users may overlook differences in labeling, and assume that the same scale has been used even when displayed scales are actually different from one another. Note that in many applications it may prove more effective to display data for comparison in a single combined chart, rather than requiring users to compare data across a series of charts. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Follow conventional scaling practice, so that values on an axis increase as they move away from the origin, and the horizontal X-axis is used to plot time or the postulated cause of an event (the independent variable) and the vertical Y-axis is used to plot a caused effect (the dependent variable). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Scaling conventions also apply to the placement of the origin of a graph. When graphed data represent positive numbers, which is usually the case, the graph should be displayed with the origin at the lower left. When the data include negative values and the axes must extend in both directions from a zero point, that origin should be displayed in the center of the graph. When the X-axis represents time intervals, the labeled scale points should represent the end of each time interval. This consistent usage will aid interpretation of all data plots, including scatterplots, line graphs, and bar charts. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a graph showing plant growth, the X-axis might show successive days, or it might show increasing amounts of water or fertilizer applied. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When on-line graphic displays must be printed, allow users to display the material exactly as it will appear in the printed output. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">On-line displays can offer some advantages over printed graphics, in terms of animation and highlighting. When a user is preparing a display for printed output, however, it is important that limitations of the print medium can be taken realistically into account. If the printed version does not appear satisfactory, it may be necessary to reformat the display in some way. Alternatively, it may be possible to find a printer with greater capabilities. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>301 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/20 Printing Graphic Displays</span></text>
</content>
<name>2.4/20</name>
<script></script>
</card>
card_81572.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When sequential relations or other connectivity between display elements requires highlighting, consider animation for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">There was a time when viewers of "sing-along" motion pictures were exhorted to "follow the bouncing ball" which marked their place. A moving marker of that kind is now often called a "sprite", or sometimes a "movable object block" (MOB). Sprites can simplify the process of animating computer-generated displays. Once a graphic element has been defined to a computer as a sprite, that element can be moved about a display independently of a fixed background or of other sprites. If only one element is shown moving on an otherwise stable display, that moving element will be seen as distinctive. Such animated highlighting is probably subject to diminishing returns. If one sprite is good for directing a user's attention, two may not be. The simultaneous display of multiple sprites may confuse a user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Connectivity might be emphasized by an arrow moving repeatedly between two displayed elements. Sequential relations might be emphasized by an animated "sprite", i.e., a moving pointer under computer control. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>300 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/19 Highlighting by Animation</span></text>
</content>
<name>2.4/19</name>
<script></script>
</card>
card_81167.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider animation, the movement of data elements under computer control, for displaying a temporal sequence of changing events, or for the pictorial display of complex objects. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Animation can be used to enhance a variety of graphic displays, including scatterplots, curves, bar graphs, flow charts, etc. Computer tools to support display animation are growing more powerful, and should find increased use in information displays. Prototype testing may be required to determine optimal timing for sequential display, which will vary with different applications. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For air traffic control, sequential frames of radar data might be displayed (with time compression) to aid perception of the tracks from moving aircraft. A complex molecular structure might be perceived more effectively if a viewer is shown sequential displays depicting a computer-stored model from different angles. An architect might demonstrate a proposed building design with a sequential "walk through" displayed from a computer-stored model. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a display has been expanded from its normal coverage, provide some graphic indicator of the position in the overall display of the visible section. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A graphic indication of the current coverage of an expanded display will provide some visual context to help a user maintain a conceptual orientation between the visible part and the whole display from which that part has been expanded. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a corner of any frame of an expanded display, the computer might show a rectangle representing the overall display, in which a smaller rectangle is placed to indicate the position and extent of the currently visible portion of that display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.8/11 Show Overview Position of Visible Section2.7.2/15 Show Overview Position of Visible Section</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>298 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/17 Show Overview Position of Visible Section</span></text>
</content>
<name>2.4/17</name>
<script></script>
</card>
card_80710.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a map or other graphic display has been expanded from its normal coverage, provide some scale indicator of the expansion factor. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications it may be helpful to show the scale even for a display with normal, unexpanded coverage. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A linear indicator of current map scale might be shown in the margin, or perhaps simply a numeric indication of the display expansion factor (e.g., </span><span class="style8">| x4 |</span><span class="style1">). </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.2/14 Show Changing Scale</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>297 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/16 Show Changing Scale</span></text>
</content>
<name>2.4/16</name>
<script></script>
</card>
card_80574.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user may need to perceive graphic relations more accurately, or to view pictures, diagrams, maps, etc. in greater detail, provide a zooming capability that allows the user to expand the display of any selected area. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Zooming can increase display spacing among crowded data items so that they can be perceived better. Thus an air traffic controller might expand a portion of a situation display to see more clearly the spacing of converging tracks that threaten a collision. Zooming can increase the degree of detail, i.e., can add data to a display. Thus a user might expand a city map to see detailed road structures that are not shown in a small-scale map. When used this way, a zooming capability implies that graphic data be "layered" hierarchically at different levels of aggregation, which may require complex data files and data management techniques. Zooming might be implemented as a continuous function, by which a display can be expanded to any degree, analogous to a continuous panning capability. Or zooming might be implemented in discrete increments, as in increasing the magnification of an optical instrument to x2, x4, etc. Incremental zooming, with abrupt changes in display scale, may tend to disorient a user, but might prove acceptable in some applications. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.2/13 Zooming for Display Expansion</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>296 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/15 Zooming for Display Expansion</span></text>
</content>
<name>2.4/15</name>
<script></script>
</card>
card_80152.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In selecting textures to code displayed areas, choose simple hatching rather than elaborate patterns. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Compared with manual drafting methods, it is temptingly easy to have a computer generate texture codes of considerable complexity. A designer should resist that temptation. When in doubt, create some sample displays and check them to ensure that texture codes do not produce distracting visual effects such as moire patterns. Texture coding is a technique specifically related to graphics. Other kinds of display coding -- size, shape, brightness, color, etc. -- can be applied more generally in display design. Display coding is considered in Section 2.6 of these guidelines. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>295 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/14 Simple Texture Codes</span></text>
</content>
<name>2.4/14</name>
<script></script>
</card>
card_80049.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design pictorial symbols (e.g., icons, pictograms) to look like the objects or processes they represent, and test the resulting symbol set with a representative group of users to ensure that the intended meanings will be understood. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some pictorial symbols have conventional meanings within a user population, which must be followed to ensure their correct interpretation. Novel symbol design must always be tested. It can happen that a symbol whose meaning seems perfectly clear to its designer may not be understood by system users. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Establish standard meanings for graphic symbols and use them consistently within a system and among systems with the same users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If users may be unfamiliar with the graphic symbology used, consider incorporating a legend to define displayed symbols. Alternatively, users might be allowed to request a supplementary display of symbol definitions or to request the definition of a particular displayed symbol by pointing at it. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, if an aircraft symbol is used to denote an aircraft on one display, that symbol should not be used to mark airfields on another display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982Hopkin Taylor 1979</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>293 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/12 Standard Symbols</span></text>
</content>
<name>2.4/12</name>
<script></script>
</card>
card_79394.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display the annotation of graphic displays, including labels for the axes of graphs, in a normal orientation for reading text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A conventional text orientation of labels will permit faster, more accurate reading. With a printed graph, it may be possible to tilt the page to read a disoriented label. With an electronic display, a user usually cannot tilt the display screen but instead must tilt his/her head. More specific recommendations for labeling different kinds of graphic displays are provided elsewhere in this section. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For users reading English, labels should be displayed horizontally, even for the vertical axis of a graph. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Noyes 1980Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>292 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/11 Normal Orientation for Labels</span></text>
</content>
<name>2.4/11</name>
<script></script>
</card>
card_79212.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Format any displayed annotation consistently in relation to the graphic elements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sometimes it might be necessary to displace a label from its "standard" position to avoid overlap or crowding on the display; such exceptions should themselves be handled consistently. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Labels might always be placed over the displayed points with which they are associated. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4/4 Consistency</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>291 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/10 Consistent Annotation Format</span></text>
</content>
<name>2.4/10</name>
<script></script>
</card>
card_79035.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When precise reading of a graphic display is required, annotate the display with actual data values to supplement their graphic representation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some displays may require complete data annotation, but many displays will require annotation only for selected data elements. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Adjacent numeric annotation might be added to the ends of displayed bars on a bar graph; numeric data might be displayed to mark the points of a plotted curve. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>290 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/9 Data Annotation</span></text>
</content>
<name>2.4/9</name>
<script></script>
</card>
card_78845.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a graph contains some outstanding or discrepant feature that merits attention by a user, consider displaying supplementary text to emphasize that feature. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation derives from the lore of audiovisual aids, where speakers are exhorted to "get the message across" with words as well as pictures. In some information system applications, a graphic display may convey many messages at once. It might then prove difficult to determine which message(s) should be stated in words. As in other aspects of display design, some priorities must be established in relation to the user's information requirements. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A flow diagram for process control might include a current advisory message, POSSIBLE PRESSURE VALVE FAILURE, as well as appropriate graphic indications of the problem. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>289 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/8 Text Annotation</span></text>
</content>
<name>2.4/8</name>
<script></script>
</card>
card_78341.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must compare graphic data to some significant level or critical value, include a reference index or baseline in the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Most data plots include a displayed baseline of some sort. An additional reference index may be displayed as well. The baseline should be chosen with care to provide an appropriate reference for displayed data. A graph without a baseline, or with a poorly chosen baseline, may distort the interpretation of displayed data. More specific recommendations for indexing different kinds of graphic displays are provided elsewhere in this section. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A horizontal line might be displayed on a profit-and-loss graph to indicate where displayed curves exceed the break-even point. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>288 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/7 Reference Index or Baseline</span></text>
</content>
<name>2.4/7</name>
<script></script>
</card>
card_78129.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user's attention must be directed to a portion of a graphic display showing critical or abnormal data, highlight that feature with some distinctive means of data coding. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">More specific recommendations for highlighting different kinds of graphic displays are provided elsewhere in this section. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">On a bar chart, one bar representing an out-of-tolerance condition might be textured or shaded differently to call attention to it and to contrast it with other bars. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/1 Highlighting Critical Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>287 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/6 Highlighting Critical Data</span></text>
</content>
<name>2.4/6</name>
<script></script>
</card>
card_78065.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Tailor graphic displays to user needs and provide only those data necessary for user tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Current advances in the technology (and theory) of graphic display permit realistic depiction of complex natural scenes. Such technology has been successfully applied to generate displays for arts and entertainment, and may also find increasing application to information displays. For many information displays, however, less may be more: an abstracted schematic diagram, omitting much detail, may convey more effective information than a photographic image. For any particular application, the amount of detail needed should be determined based on a task analysis. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tucker 1984Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/2 Only Necessary Data Displayed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>286 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/5 Only Necessary Information Displayed</span></text>
</content>
<name>2.4/5</name>
<script></script>
</card>
card_77695.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use consistent logic in the design of graphic displays, and maintain standard format, labeling, etc., for each method of graphic presentation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistency in graphic design will allow users to focus on changes in displayed data without being distracted by changes in display format. The standardization advocated here has to do with the logic of user interface design, not with internal processing by graphics software. Recent efforts to establish international standards for graphics software have been focused on the internal encoding, processing, storage and transmission of graphics displays in digital form. Such data processing standards do not in themselves specify or significantly constrain user interface design. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Tufte 1983</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>285 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/4 Consistency</span></text>
</content>
<name>2.4/4</name>
<script></script>
</card>
card_77453.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users must monitor changing data, consider graphic format to display the data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Whenever possible, the computer should handle data monitoring and should call abnormalities to the user's attention. When that is not possible, and a user must monitor data changes, graphic display will make it easier for the user to detect critical changes and/or values outside the normal range. The current lore of graphic design derives chiefly from static, printed displays. Computer processing, however, offers a potential for continuous dynamic display of changing data that should be considered in all methods of graphic presentation. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hanson etal 1981Tullis 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>284 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/3 Monitoring Data Change</span></text>
</content>
<name>2.4/3</name>
<script></script>
</card>
card_77104.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When users must quickly scan and compare related sets of data, consider graphic format to display the data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Graphic display might help users discern errors in a data base, since deviant "outliers" will appear visually distinct from the body of correct data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.2.9MIL-STD-1472C 1983 § 5.15.3.6.1Cleveland 1985</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>283 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/2 Data Comparison</span></text>
</content>
<name>2.4/2</name>
<script></script>
</card>
card_76855.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider graphics rather than text description or tabulation, for display of data showing relations in space or time. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">People cannot readily assimilate detailed textual or tabular data, although sometimes such data are necessary. Therefore, a graphic display might be designed where graphic elements showing trends and differences are combined with text annotation and tabular presentation of detailed data. In some applications, it might prove helpful to supplement a primary graphic display with alternative displays of detailed data available as a user-selected option. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.6.1Foley Van Dam 1982Stewart 1980</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>282 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.4 Graphics</span><span class="style21">2.4/1 Graphic Displays</span></text>
</content>
<name>2.4/1</name>
<script></script>
</card>
card_76753.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must enter numeric values that will later be displayed, maintain all significant zeros; zeros should not be arbitrarily removed after a decimal point if they affect the meaning of the number in terms of significant digits. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.4.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.5/8 Maintaining Significant Zeros2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>281 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/17 Maintaining Significant Zeros</span></text>
</content>
<name>2.3/17</name>
<script></script>
</card>
card_76513.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Justify columns of numeric data with respect to a fixed decimal point; if there is no decimal point, then numbers should be right-justified. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Show columns of alphabetic data with left justification to permit rapid scanning. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Indentation can be used to indicate subordinate elements in hierarchic lists. A short list, of just four or five items could be displayed horizontally on a single line, in the interests of compact display format, if that is done consistently. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) (Bad) </span><span class="style8">| APL | | APL | | COBOL | | COBOL | | FORTRAN | | FORTRAN | | PL1 | | PL1 | </span><span class="style1">See sample displays in section 2.3/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In dense tables with many rows, insert a blank line (or some other distinctive feature to aid horizontal scanning) after a group of rows at regular intervals. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For many applications it will suffice to insert a blank line after every five rows.See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.5/10 Row Scanning Cues2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>278 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/14 Row Scanning Cues</span></text>
</content>
<name>2.3/14</name>
<script></script>
</card>
card_75679.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Separate the columns in a table by enough blank spaces, or by some other distinctive feature, to ensure separation of entries within a row. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For most tables, a column separation of at least three spaces should be maintained. Certainly the spacing between columns should be greater than any internal spaces that might be displayed within a tabulated data item. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.6</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>277 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/13 Column Scanning Cues</span></text>
</content>
<name>2.3/13</name>
<script></script>
</card>
card_75457.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Maintain consistent column spacing within a table, and from one table to another. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When columns are grouped under superheadings, it may help to add extra space between superheadings, in order to emphasize that the columns under any single superheading are related. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2/11 Consistent Format Across Displays2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>276 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/12 Consistent Column Spacing</span></text>
</content>
<name>2.3/12</name>
<script></script>
</card>
card_75011.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In tabular displays, either consistently include the units of displayed data in the column labels, or else place them after the first row entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Time Velocity Temperature | | (s)_ (m/s)___ (0C)_______ | | 5 8 25 | | 21 49 29 | | 43 87 35 | </span><span class="style1">(Also acceptable) </span><span class="style8">| Time Velocity Temperature | | 5 s 8 m/s 25 0C | | 21 49 29 | | 43 87 35 | </span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.8</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>275 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/11 Labeling Units of Measurement</span></text>
</content>
<name>2.3/11</name>
<script></script>
</card>
card_74915.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For hierarchic lists with compound numbers, display the complete numbers; do not omit repeated elements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Implicit numbering, as in the "bad" example, may be acceptable for tasks involving perception of list structure. Complete numbering is better, however, for tasks requiring search and identification of individual items in the list. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| 2.1 Position Designation | | 2.1.1 arbitrary positions | | 2.1.1.1 discrete | | 2.1.1.2 continuous | | 2.1.2 predefined positions | | 2.1.2.1 HOME | | 2.1.2.2 other | </span><span class="style1">(Bad) </span><span class="style8">| 2.1. Position Designation | | 1. arbitrary positions | | 1 discrete | | 2 continuous | | 2. predefined positions | | 1 HOME | | 2 other | </span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Smith Aucella 1983b</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>274 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/10 Repeated Elements in Hierarchic Numbering</span></text>
</content>
<name>2.3/10</name>
<script></script>
</card>
card_74519.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When rows or columns are labeled by number, start the numbering with "1", rather than "0". </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In counting, people start with "one"; in measuring, they start with "zero". </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.2.6</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>273 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/9 Numbered Items Start with 1</span></text>
</content>
<name>2.3/9</name>
<script></script>
</card>
card_74473.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that row and column labels are distinguishable from the data displayed within tables, and from the labels of displayed lists such as menu options or instructions to users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">There are many ways to distinguish different types of labeled material, including consistent differences in display format/placement as well as special fonts and markers. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.2.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison3.1.3/20 Menus Distinct from Other Displayed Information</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>272 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/8 Distinctive Labeling</span></text>
</content>
<name>2.3/8</name>
<script></script>
</card>
card_74009.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt a consistent format for labeling the rows and columns of displayed tables. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent left justification of column labels will prove especially helpful when columns vary in width. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Each column label might be left-justified with the leftmost character of the column entries beneath it. See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hartley Young Burnhill 1975</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/6 Consistent Display Format2.3/1 Tables for Data Comparison4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>271 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/7 Consistent Label Format</span></text>
</content>
<name>2.3/7</name>
<script></script>
</card>
card_73888.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Label the rows and columns of tabular displays following the guidelines proposed for labeling the fields of data forms. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.8.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2 Data Forms2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>270 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/6 Row and Column Labels</span></text>
</content>
<name>2.3/6</name>
<script></script>
</card>
card_73528.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If data items must be compared on a character-by-character basis, display one directly above the other. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">But remember that users will not be entirely accurate in making such comparisons; automated comparison by computer analysis would be more reliable. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.1.8</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>269 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/5 Items Paired for Direct Comparison</span></text>
</content>
<name>2.3/5</name>
<script></script>
</card>
card_73420.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When tables are used for reference, display the reference items, i.e., those by which the table will be accessed, in the left column; display the material most relevant for user response in the next adjacent column; and display associated but less significant material in columns further to the right. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">As a corollary, when a list of people is ordered alphabetically by their last name, then their last names should be displayed first, i.e., as the leftmost element in each row. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Hamill 1980Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>268 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/4 Tables Referenced by First Column</span></text>
</content>
<name>2.3/4</name>
<script></script>
</card>
card_73071.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Construct a table so that row and column labels represent the information a user has prior to consulting the table, i.e., the information that can be used to access table entries for a particular task. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user's task were to determine characteristics of various raw materials, then a table might be organized as </span><span class="style8">| Raw Transport Processing Consumer | | Material Costs Time Acceptance | | A High Slow Good | | B High Fast Good | | C Low Slow Good | | D High Slow Poor | | E High Fast Poor | | F Low Fast Poor | </span><span class="style1">whereas if the user's task were to identify what raw material meets certain criteria, then the table might be organized as </span><span class="style8">| Consumer | | Acceptance | | Good Poor | | | | High Fast Processing B E | | Transport | | Costs Slow Processing A D | | | | Low Fast Processing F | | Transport | | Costs Slow Processing C | </span><span class="style1">See sample displays in section 2.3/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>267 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/1 Tables for Data Comparison</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/3 Table Access by Row and Column</span></text>
</content>
<name>2.3/3</name>
<script></script>
</card>
card_72871.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Organize tabular data in some recognizable order to facilitate scanning and assimilation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Dates might be ordered chronologically, names alphabetically.See sample displays in section 2.3/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When information handling requires detailed comparison of ordered sets of data, adopt a tabular format for data display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">These sample displays represent a table for finding the owner of a car with a particular license plate. (Perhaps it is an employee who has parked in the wrong place, or who has left headlights burning.) In the good display, data entries are ordered by license number to aid the search. The bad display is ordered alphabetically by employees' last name, which will not prove helpful for this task. The bad display is annotated to indicate several other violations of the design guidelines proposed here for tabular displays. Good Sample Tabular Display </span><span class="style8">|----------------------------------------------------------| | AUTOMOBILE OWNERS Page 1 of 4 | | | | LICENSE EMPLOYEE EXT DEPT | | | | MA 127 355 Michaels, Allison 7715 91 | | MA 135 449 Duvet, William 3898 81 | | MA 227 379 Smithson, Jill 2491 63 | | MA 227 GBH Zadrowski, Susan 2687 53 | | MA 253 198 Jenskin, Erik 3687 31 | | | | MA 286 PAM Hilsmith, Joseph 2443 100 | | MA 291 302 Leonard, John 7410 92 | | MA 297 210 Toth, Kelley 7538 45 | | MA 328 647 Cooksey, Roger 2144 64 | | MA 342 NCG Hesen, Christopher 7544 21 | | | | MA 367 923 Maddox, Patrick 7070 66 | | MA 375 NRC Ashley, Maria 3397 34 | | MA 376 386 Wheetley, Katherine 2638 58 | | MA 385 248 Malone, Frank 2144 64 | | MA 391 293 Lowman, Edward 8263 77 | | | | n = Next page | | < | |----------------------------------------------------------| </span><span class="style1">This bad tabular display violates in some degree several design guidelines in this section: 2.3/2 Logical organization 2.3/4 Tables referenced by first column 2.3/6 Row and column labels 2.3/12 Consistent column spacing 2.3/13 Column scanning cues 2.3/14 Row scanning cues 2.3/16 Justification of numeric data Various other guidelines are also violated in this bad table, including those pertaining to identification of multipage displays and display of control options. Bad Sample Tabular Display </span><span class="style8">|----------------------------------------------------------| | Automobile Owners | | Sara Alwine 2438 MA 929 448 103 | | Christopher Aranyi 2716 MA 797 AND 97 | | Maria Ashley 3397 MA 375 NRC 34 | | Arlene Atchison 7672 NH 60731 28 | | Steven Bahr 3272 MA 635 203 35 | | David Baldwin 3295 NH 63577 75 | | David Benkley 3581 MA 589 ADE 58 | | Marlin Boudreau 3413 MA 816 HER 93 | | Roger Cooksey 2144 MA 328 647 64 | | Joseph Curran 3167 RI 4693 83 | | Kent Delacy 3619 MA 749 827 29 | | Susan Doucette 2797 MA 525 115 41 | | Joseph Drury 7604 NH 42265 27 | | William Duvet 3898 MA 135 449 81 | | Samuel Everett 3619 MA 635 ASK 29 | | Jeanne Fiske 7642 MA 614 CSU 10 | | Nancy Graham 2358 MA 745 CKJ 10 | | Paul Greenbaum 3979 MA 846 BLN 103 | | Christopher Hesen 7544 MA 342 NCG 21 | | Joseph Hilsmith 2443 MA 286 PAM 100 | | | | | | < | |----------------------------------------------------------| </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>265 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/2 Logical organization 2.3/4 Tables referenced by first column 2.3/6 Row and column labels 2.3/12 Consistent column spacing 2.3/13 Column scanning cues 2.3/14 Row scanning cues 2.3/16 Justification of numeric data </text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.3 Tables</span><span class="style21">2.3/1 Tables for Data Comparison</span></text>
</content>
<name>2.3/1</name>
<script></script>
</card>
card_72229.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Distinguish blanks (keyed spaces) from nulls (no entry at all) in the display of data forms, where that can aid task performance. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some special symbol might be adopted to denote null entry. If field delimiters are displayed to guide data entry, then it will often be sufficient simply to leave those delimiters unchanged when no entry has been made. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/10 Marking Field Boundaries2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>264 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/15 Distinguishing Blanks from Nulls</span></text>
</content>
<name>2.2/15</name>
<script></script>
</card>
card_72059.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Divide long data items of mixed alphanumeric characters into subgroups of three or four characters separated by a blank or by some special symbol. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Hyphens may be used instead of blanks where that is customary. Slashes are less preferred for separating groups, since they are more easily confused with alphanumerics. Where a common usage has been established, as in the NNN-NN-NNNN of US social security numbers, grouping should follow that usage. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Words should be displayed intact, whatever their length. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.2.2MIL-STD-1472C 1983 § 5.15.3.1.7 5.15.3.5.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/16 Partitioning Long Data Items2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>263 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/14 Partitioning Long Data Items</span></text>
</content>
<name>2.2/14</name>
<script></script>
</card>
card_71687.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the internal format of frequently used data fields is consistent from one display to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The convention chosen should be familiar to the prospective users. For European users, the customary format for telephone numbers and dates is different than suggested in the examples above. For military users, date-time data are frequently combined in an accepted special format. For many user groups, time records are kept on a 24-hour clock, which should be acknowledged in display formatting. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Telephone numbers should be consistently punctuated, perhaps as 213-394-1811. Time records might be consistently punctuated with colons, as HH:MM:SS or HH:MM or MM:SS.S, whatever is appropriate. Date records might be consistently formatted with slashes, as MM/DD/YY. See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.2.17</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>262 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/13 Consistent Format Within Data Fields</span></text>
</content>
<name>2.2/13</name>
<script></script>
</card>
card_71480.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When forms are used for data entry as well as for data display, ensure that the format for data display is compatible with whatever format is used for data entry; use the same item labels and ordering for both. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/24 Form Compatible for Data Entry and Display2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>261 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/12 Form Compatible for Data Entry and Display</span></text>
</content>
<name>2.2/12</name>
<script></script>
</card>
card_71387.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the ordering and layout of corresponding data fields is consistent from one display to another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
<text>2.2/1 Forms for Related Data2.3/12 Consistent Column Spacing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>260 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/11 Consistent Format Across Displays</span></text>
</content>
<name>2.2/11</name>
<script></script>
</card>
card_71099.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Include the units of measurement for displayed data either in the label or as part of each data item. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| DISTANCE (KM): __ __ __ | </span><span class="style1">or </span><span class="style8">| DISTANCE: __ __ __ KM | </span><span class="style1">See sample displays in section 2.2/1.</span></text>
<text>1.4/21 Labeling Units of Measurement2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>259 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/10 Labeling Units of Measurement</span></text>
</content>
<name>2.2/10</name>
<script></script>
</card>
card_70861.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that each label is sufficiently close to be associated with its data field, but is separated from its data field by at least one space. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.9.5Engel Granda 1975 § 2.3.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2/1 Forms for Related Data1.4/8 Labels Close to Data Fields</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>258 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/9 Labels Close to Data Fields</span></text>
</content>
<name>2.2/9</name>
<script></script>
</card>
card_70500.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that labels are distinctive in format/positioning to help users distinguish them from data and other display features. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Labels might be capitalized when data are displayed in mixed case, or might be dim when data are bright, or might perhaps be displayed in a different font where that capability exists. See sample displays in this section. See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.2.3MIL-STD-1472C 1983 § 5.15.3.1.10.c 5.15.4.3.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2/1 Forms for Related Data4.0/8 Distinctive Format for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>257 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/8 Distinctive Label Format</span></text>
</content>
<name>2.2/8</name>
<script></script>
</card>
card_70301.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Place each label in a consistent location above or to the left of its associated data field(s). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent alignment of labels and data will aid display scanning by a user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a numbered list, vertically formatted, the numeric labels should be aligned so that the data items start in a fixed column position on the display. See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.9MIL-STD-1472C 1983 § 5.15.3.1.10.a</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2/1 Forms for Related Data2.3 Tables</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>256 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/7 Consistent Label Location</span></text>
</content>
<name>2.2/7</name>
<script></script>
</card>
card_69962.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that field labels are worded distinctively from one another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.5Engel Granda 1975 § 3.2.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>255 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/6 Distinctive Wording of Labels</span></text>
</content>
<name>2.2/6</name>
<script></script>
</card>
card_69688.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that labels are worded consistently, so that the same data item is given the same label if it appears in different displayed forms. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It may also help to employ consistent grammatical format for different labels; i.e., do not use single words or phrases for some labels and short sentences for others, or use verbs for some and nouns for others. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
<text>2.2/1 Forms for Related Data4.0/23 Consistent Grammatical Structure</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>254 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/5 Consistent Wording of Labels</span></text>
</content>
<name>2.2/5</name>
<script></script>
</card>
card_69610.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose a word or phrase to label each field that will describe the data content of that field. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Labels should be worded carefully so that they assist users in scanning the display and assimilating information quickly. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/4 Descriptive Wording of Labels</span></text>
</content>
<name>2.2/4</name>
<script></script>
</card>
card_69194.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Identify each data field with a displayed label. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not assume that the user can identify individual data fields because of past familiarity. Context may play a significant role: 617-271-7768 might be recognized as a telephone number if seen in a telephone directory, but might not be recognized as such in an unlabeled display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
<text>1.4/5 Data Field Labels1.4/6 Consistent Labeling1.4/7 Protected Labels1.4/8 Labels Close to Data Fields2.2/1 Forms for Related Data4.0/11 Clear Data Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>252 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/3 Data Field Labeling</span></text>
</content>
<name>2.2/3</name>
<script></script>
</card>
card_68686.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide clear visual definition of data fields, so that the data are distinct from labels and other display features. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.2/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.3.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/6 Defined Display Areas for Data Entry1.4/10 Marking Field Boundaries2.2/1 Forms for Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>251 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/2 Visually Distinctive Data Fields</span></text>
</content>
<name>2.2/2</name>
<script></script>
</card>
card_68576.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">∆ Statement</span><span class="style1">Use forms to display related sets of data items in separately labeled fields. </span><span class="style10">∆∆ Comment</span><span class="style1">Forms can aid review of related data items by displaying explanatory labels to caption each data field. </span><span class="style10">∆∆ Example </span><span class="style1">These sample displays represent a possible form for review (and possible revision) of visa application data. In the good display, data entries are bolded to help distinguish them from labels and field delimiters. Fields are ordered consistently in relation to a (supposed) paper application form, and formatted to facilitate data review. The bad display is annotated to indicate violations of several of the design guidelines proposed here for data form displays. The data entries in the bad display were invented to suggest what a user might have entered, if confused by inadequate labeling and the absence of field delimiters. Good Sample Data Form Display </span><span class="style8">|----------------------------------------------------------| | VISA APPLICATION | | | | NAME: Jones, Andrew David VISA: 356 478 | | LAST, FIRST MIDDLE | | | | BIRTH COUNTRY: UK DATE: 3/22/25 | | M D Y | | | | NATIONALITY: UK PASSPORT: Z196284 | | | | ADDRESS: 5 Fairview Lane | | Loughborough, LE11 3RG | | England | | | | OTHER TRAVELERS ON THIS VISA | | BIRTH | | NAME: COUNTRY: DATE: | | Jones, Sandra Jean UK 10/11/28 | | Jones, Cynthia Leigh FR 6/12/68 | | __________________________ __ __/__/__ | | __________________________ __ __/__/__ | | LAST, FIRST MIDDLE M D Y | | | | * Review and ENTER changes if needed. | |----------------------------------------------------------| </span><span class="style1">Bad Sample Data Form Display </span><span class="style8">|----------------------------------------------------------| | Name Andrew D. Jones Visa Number 356478 | | | | Birthplace London Nationality English | | | | Passport Z196284 Birthdate Mar. 22, | | | | Address 1925 | | 5 Fairview Lane, Loughborough, L | | E11 3RG, England | | | | Other travelers on this visa | | Traveler's Name Date of Birth - Place | | Sandra J. Jones Oct. 11, - 1928 | | Birmingham | | Cynthia L. Jones June 12, - 1968 | | Paris, France | | | | | | | | | | | | | | | | Review and ENTER changes if needed | |----------------------------------------------------------| </span><span class="style1">This bad data form display violates in some degree several design guidelines in this section: 2.2/2 Visually distinctive data fields 2.2/4 Descriptive wording of labels 2.2/5 Consistent wording of labels 2.2/8 Distinctive label format 2.2/14 Partitioning long data items 2.2/15 Distinguishing blanks from nulls This bad data form also violates various design guidelines pertaining to data entry, as noted at the end of Section 1.4. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>250 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.2 Data Forms</span><span class="style21">2.2/1 Forms for Related Data</span></text>
</content>
<name>2.2/1</name>
<script></script>
</card>
card_68341.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When tables and/or graphics are combined with text, place each figure near its first citation in the text, preferably in the same display frame. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Readers may not bother to find and look at a figure is it is displayed separately from its citation in the text. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If a figure is cited at several points in the text, then it might be desirable to allow optional display of the figure at user request, perhaps as a temporary window overlay at each point of citation. If a figure is cited at several points in printed text, and particularly if that text may be accessed at different places by its readers (as in the case of printed reference material), then it might be desirable to group figures consistently at a particular location, such as at the end of each section. </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Whalley Fleming 1975</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>249 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/29 Placing Figures Near Their Citations</span></text>
</content>
<name>2.1/29</name>
<script></script>
</card>
card_67857.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When text is combined with graphics or other data in a single display, thus limiting the space available for text, format the text in a few wide lines rather than in narrow columns of many short lines. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Listed items might be displayed in a narrow column format. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Text is easier to read when displayed in wide | | lines than when displayed in thin columns. | </span><span class="style1">(Bad) </span><span class="style8">| Text is harder | | to read when | | displayed in | | thin columns | | than when | | displayed in | | wide lines. | </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Duchnicky Kolers 1983</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display2.1/5 Text Displayed in Wide Columns</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>248 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/28 Combining Text with Other Data</span></text>
</content>
<name>2.1/28</name>
<script></script>
</card>
card_67769.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a critical passage merits emphasis to set it apart from other text, highlight that passage by bolding/brightening or color coding or by some auxiliary annotation, rather than by capitalization. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A single word might be capitalized for emphasis, but capitalizing an extended passage will reduce its readability. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display2.1/6 Conventional Use of Mixed Case</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>247 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/27 Highlighting Text</span></text>
</content>
<name>2.1/27</name>
<script></script>
</card>
card_67430.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When words in text displays are abbreviated, define each abbreviation in parentheses following its first appearance. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will help only those users who read displayed text from front to back and remember what they have read. For forgetful users, and for users who sample later sections of a multipage text display, abbreviations may still seem undefined. For such users, it might be helpful to provide an on-line dictionary of abbreviations for convenient reference. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.1.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display4.4/20 Dictionary of Abbreviations</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>246 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/26 Abbreviations Defined in Text</span></text>
</content>
<name>2.1/26</name>
<script></script>
</card>
card_67165.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For a long list, extending more than one displayed page, consider adopting a hierarchic structure to permit its logical partitioning into related shorter lists. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>245 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/25 Hierarchic Structure for Long Lists</span></text>
</content>
<name>2.1/25</name>
<script></script>
</card>
card_66829.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Adopt some logical principle by which to order lists; where no other principle applies, order lists alphabetically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is the user's logic which should prevail rather than the designer's logic, where those are different. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.1MIL-STD-1472C 1983 § 5.15.3.5.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display2.3/2 Logical Organization2.5/14 Data Grouped by Sequence of Use2.5/15 Data Grouped by Function2.5/16 Data Grouped by Importance2.5/17 Data Grouped by Frequency2.5/18 Data Grouped Alphabetically or Chronologically</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>243 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/23 Logical List Ordering</span></text>
</content>
<name>2.1/23</name>
<script></script>
</card>
card_66548.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When listed items will be numbered, use Arabic rather than Roman numerals. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Arabic numbers are more familiar to most users, and therefore require less interpretation than Roman numerals do. The advantage of Arabic numbers becomes greater when large numbers are used. For instance, contrast XXVIII with 28. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>242 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/22 Arabic Numerals for Numbered Items</span></text>
</content>
<name>2.1/22</name>
<script></script>
</card>
card_66107.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a single item in a list continues for more than one line, mark items in some way so that the continuation of an item is obvious, i.e., so that a continued portion does not appear to be a separate item. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some demarcation is particularly needed when a list is comprised of a mixture of long and short items. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Items might be separated by a blank space, or continuing lines within an item might be indented, or each item might be numbered or marked by a special symbol such as an arrow or bullet. </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>241 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/21 Marking Multiline Items in a List</span></text>
</content>
<name>2.1/21</name>
<script></script>
</card>
card_65922.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Format lists so that each item starts on a new line; i.e., a list should be displayed as a single column. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Listing in multiple columns may be considered where shortage of display space dictates a compact format. Multiple columns of data should be used where that facilitates comparison of corresponding data sets, as in tabular displays (Section 2.3). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Major USI functional areas include | | | | Data Entry | | Data Display | | Sequence Control | | User Guidance | | Data Transmission | | Data Protection | </span><span class="style1">(Bad) </span><span class="style8">| Major USI functional areas include | | | | Data Entry Data Display | | Sequence Control User Guidance | | Data Transmission Data Protection | </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
<text>2.1/1 Conventional Text Display3.1.3/3 Single-Column List Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>240 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/20 Single-Column List Format</span></text>
</content>
<name>2.1/20</name>
<script></script>
</card>
card_65606.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For a series of related items (words, phrases, instructions, etc.), display those items in a list rather than as continuous text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A list format will facilitate rapid, accurate scanning. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.3.2Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>239 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/19 Lists for Related Items</span></text>
</content>
<name>2.1/19</name>
<script></script>
</card>
card_65383.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a sentence describes a sequence of events, phrase it with a corresponding word order. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Temporal order is clearer. Reverse order may confuse a user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Enter LOGON before running programs. | </span><span class="style1">(Bad) </span><span class="style8">| Before running programs enter LOGON. | </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.6Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display4.0/22 Temporal Sequence</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>238 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/18 Temporal Sequence</span></text>
</content>
<name>2.1/18</name>
<script></script>
</card>
card_65157.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Compose sentences in the active rather than passive voice. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Sentences in the active voice will generally be easier to understand. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Clear the screen by pressing RESET. | </span><span class="style1">(Bad) </span><span class="style8">| The screen is cleared by pressing RESET. | </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.5Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display4.0/21 Active Voice</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>237 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/17 Active Voice</span></text>
</content>
<name>2.1/17</name>
<script></script>
</card>
card_64822.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use affirmative statements rather than negative statements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Tell the user what to do rather than what to avoid. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Clear the screen before entering data. | </span><span class="style1">(Bad) </span><span class="style8">| Do not enter data before clearing the screen. | </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.3Wright 1977</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display4.0/20 Affirmative Statements</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>236 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/16 Affirmative Sentences</span></text>
</content>
<name>2.1/16</name>
<script></script>
</card>
card_64551.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use distinct words rather than contractions or combined forms, especially in phrases involving negation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This practice will help users understand the sense of a message. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) "will not", "not complete" (Bad) "won't", "incomplete" </span><span class="style10"></span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.1.4Engel Granda 1975 § 2.2.15</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>235 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/15 Distinct Wording</span></text>
</content>
<name>2.1/15</name>
<script></script>
</card>
card_64288.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When speed of display output for textual material is slower than the user's normal reading speed, make an extra effort to word the text concisely. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Assume a normal average reading speed of 250 words per minute. The goal here is to make wording concise but not cryptic. Omitting articles ("the", "a"), prepositions ("of", "by") and relative pronouns ("that", "which", "who") may save some space, but may also reduce comprehension. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.3.7</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display4.3/5 Brief Error Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>234 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/14 Concise Wording</span></text>
</content>
<name>2.1/14</name>
<script></script>
</card>
card_64122.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use short simple sentences. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Long sentences with multiple clauses may confuse the user. Consider breaking long sentences into two or more shorter statements. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Put the main topic of each sentence near the beginning of the sentence. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.8.2</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>232 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/12 Sentences Begin with Main Topic</span></text>
</content>
<name>2.1/12</name>
<script></script>
</card>
card_63657.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In designing text displays, especially text composed for user guidance, strive for simplicity and clarity of wording. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>231 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/11 Clarity of Wording</span></text>
</content>
<name>2.1/11</name>
<script></script>
</card>
card_63295.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use conventional punctuation in textual display; sentences should end with a period or other special punctuation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.3.4Engel Granda 1975 § 2.2.13</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>230 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/10 Conventional Punctuation</span></text>
</content>
<name>2.1/10</name>
<script></script>
</card>
card_63127.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In display of textual material, keep words intact, with minimal breaking by hyphenation between lines. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Text is more readable if each word is entirely on one line, even if that makes the right margin more ragged. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.2Engel Granda 1975 § 2.2.10</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/19 Hyphenation by Users2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>229 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/9 Minimal Hyphenation</span></text>
</content>
<name>2.1/9</name>
<script></script>
</card>
card_62740.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Maintain consistent spacing between the words of displayed text, with left justification of lines and ragged right margins if that is the result. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Reading is easier with constant spacing, which outweighs the advantage of an even right margin achieved at the cost of uneven spacing. Uneven spacing is a greater problem with narrow column formats than with wide columns. Uneven spacing handicaps poor readers more than good readers. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Right justification should be employed if it can be achieved by variable spacing, maintaining constant proportional differences in spacing between and within words, and consistent spacing between words in a line. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that displayed paragraphs of text are separated by at least one blank line. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 2.3.4MIL-STD-1472C 1983 § 5.15.3.7.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>227 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/7 Separation of Paragraphs</span></text>
</content>
<name>2.1/7</name>
<script></script>
</card>
card_62255.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display continuous text conventionally in mixed upper and lower case. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Reading text is easier when capitalization is used conventionally to start sentences and to indicate proper nouns and acronyms. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">An item intended to attract the user's attention, such as a label or title, might be displayed in upper case. Upper case should be used when lower case letters will have decreased legibility, e.g., on a display terminal that cannot show true descenders for lower case letters. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/6 Conventional Use of Mixed Case</span></text>
</content>
<name>2.1/6</name>
<script></script>
</card>
card_61981.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display continuous text in wide columns, containing at least 50 characters per line. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Text displayed in wide columns will be read significantly faster than text displayed in narrow columns. When space for text display is limited, display a few long lines of text rather than many short lines of text. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Duchnicky Kolers 1983</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display2.1/28 Combining Text with Other Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>225 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/5 Text Displayed in Wide Columns</span></text>
</content>
<name>2.1/5</name>
<script></script>
</card>
card_61819.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must read continuous text on line, display at least four lines of text at one time. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Four lines of text is the minimum which should be displayed when the reading material is simple in content. If the content is more complex, or if a reader will need to refer frequently to previous material, then display more lines of text. When space for text display is limited, display a few long lines of text rather than many short lines of text. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Duchnicky Kolers 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>224 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/4 Adequate Display Capacity</span></text>
</content>
<name>2.1/4</name>
<script></script>
</card>
card_61481.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When textual material is formatted, as in structured messages, adopt a consistent format from one display to another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/6 Consistent Display Format2.1/1 Conventional Text Display</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>223 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/3 Consistent Text Format</span></text>
</content>
<name>2.1/3</name>
<script></script>
</card>
card_61303.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must read lengthy textual material, consider providing that text in printed form rather than requiring the user to read it on-line. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Reading lengthy text on an electronic display may be 20-30 percent slower than reading it from a printed copy. There are many good reasons for displaying lengthy textual material on line. Lengthy text may be displayed for editing, mailing, or search tasks. Or a lengthy text might be updated frequently, and so on-line display would be the best way to ensure that all users are reading the most recent version. The intent of this guideline is not to discourage such on-line display of text when that is needed, but rather to discourage on-line display when the text would be more useful in paper form. For instance, if HELP displays consist merely of screen after screen of text which is not tailored to a user's current task, than that text might be better displayed in a printed users' manual. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 2.1/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that computer-generated displays of textual data, messages, or instructions, will generally follow design conventions for printed text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1"> Adoption of familiar design conventions for text display will permit users to rely on prior reading skills. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">These sample displays represent a broadcast message received by all users logging onto an on-line office support system. The wording of the bad display is taken from an actual instance. The good display clarifies wording of the text and improves display formatting. The bad display is annotated to indicate violations of several of the design guidelines proposed here for text display. Although most of its noted deficiencies are minor, in sum they create a display that is potentially confusing to its users. Good Sample Text Display </span><span class="style8">|----------------------------------------------------------| | SYSTEM BROADCAST MESSAGES | | | | 27 March 1984 | | | | Word Processing Users: | | | | Please do NOT print multiple copies of large | | documents (more than 100 printed pages) during normal | | working hours. Large print requests will delay | | printing service for all users. | | | | If you do need bulk printing, submit your request | | before leaving at 4:30 pm. Your printouts will be | | ready by the next morning. | | | | Network Users: | | | | Please report any net-related problems to the | | User Support Center, x2222. | | | | | | | | * Press CONTINUE to display the Office Systems Menu. | | < | |----------------------------------------------------------| </span><span class="style1">Bad Sample Text Display </span><span class="style8">|----------------------------------------------------------| | -- System Broadcast Messages -- | | SYSTEM #22 - WPS 27 March 1984 | | | | **** NOTICE **** | | | | WPS USERS ARE REMINDED NOT TO PRINT MULTIPLE | | COPIES OF LARGE SIZE DOCUMENTS (100 PAGES OR | | MORE) TO THE 6670 PRINTER OR LINEPRINTER SINCE IT | | CAUSES LONG DELAYS ON THOSE PRINTERS. | | IF YOU NEED MULTIPLE COPIES, PLEASE SUBMIT | | YOUR REQUEST BEFORE LEAVING AT 4:30 P.M. THANK | | YOU. | | ****** | | | | NETWORK USERS -- Please report any network | | related problems to the User Support Center, | | X2222. | | | | Questions or problems should be referred to the | | USC, X2222. | | | | Press the RETURN key to enter the Office Systems | | Menu | | < | |----------------------------------------------------------| </span><span class="style1">This bad text display violates in some degree several design guidelines in this section: 2.1/1 Conventional text display 2.1/3 Consistent text format 2.1/6 Conventional use of mixed case 2.1/7 Separation of paragraphs 2.1/8 Consistent word spacing 2.1/10 Conventional punctuation 2.1/11 Clarity of wording 2.1/13 Simple sentence structure </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>221 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/3 Consistent text format 2.1/6 Conventional use of mixed case 2.1/7 Separation of paragraphs 2.1/8 Consistent word spacing 2.1/10 Conventional punctuation 2.1/11 Clarity of wording 2.1/13 Simple sentence structure </text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.1 Text</span><span class="style21">2.1/1 Conventional Text Display</span></text>
</content>
<name>2.1/1</name>
<script></script>
</card>
card_60691.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If abbreviations are used, provide a dictionary of abbreviations available for on-line user reference. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/21 Dictionary of Abbreviations</span></text>
</content>
<name>2.0/21</name>
<script></script>
</card>
card_60460.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Minimize punctuation of abbreviations and acronyms. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Punctuation should be retained when needed for clarity, e.g., "4-in. front dimension" rather than "4 in front dimension". Punctuation of abbreviations might be justified when an abbreviation represents more than one word, and more than the first letter of each word is included in the abbreviation, e.g., "common services" abbreviated as "COM.SER" rather than "COMSER". </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| USAF | </span><span class="style1">(Bad) </span><span class="style8">| U.S.A.F. | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that abbreviations are distinctive, so that abbreviations for different words are distinguishable. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When defining abbreviations, follow some simple rule and ensure that users understand that rule. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Abbreviation by truncation is the best choice, except when word endings convey important information. When a truncation rule is used, abbreviations are easy for a designer to derive and easy for a user to decode. If an abbreviation deviates from the consistent rule, it may be helpful to give it some special mark whenever it is displayed. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When abbreviations are used, choose those abbreviations that are commonly recognized, and do not abbreviate words that produce uncommon or ambiguous abbreviations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The point here is that when abbreviation is necessary due to space constraints, often a designer can still choose which words will be abbreviated. The words chosen for abbreviation should be those that are commonly known in their abbreviated form, and/or those words whose abbreviations can be unambiguously interpreted. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a process control application where system components are commonly abbreviated, messages to users could include those common abbreviations, while displaying in full form those words that are not commonly abbreviated, as (Acceptable) </span><span class="style8">| CST pressure low |</span><span class="style1"> (Poor) </span><span class="style8">| Condensate Storage Tank prssr lw | </span><span class="style1">(Acceptable) </span><span class="style8">| Restricted Acct | </span><span class="style1">(Poor) </span><span class="style8">| Rstr Account | </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.1.6</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>216 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/17 Common Abbreviations</span></text>
</content>
<name>2.0/17</name>
<script></script>
</card>
card_59640.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display complete words in preference to abbreviations. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Abbreviations may be displayed if they are significantly shorter, save needed space, and will be understood by the prospective users. When abbreviations are used for data entry, then corresponding use of those abbreviations in data display may help a user learn them for data entry. </span></text>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/16 Minimal Use of Abbreviation</span></text>
</content>
<name>2.0/16</name>
<script></script>
</card>
card_59209.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use consistent grammatical structure for data and labels within and across displays. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Even minor inconsistencies can distract a user and delay comprehension as the user wonders momentarily whether some apparent difference represents a real difference. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Starting date: | | Leaving date: | | Home phone: | | Work phone: | </span><span class="style1">(Bad) </span><span class="style8">| Starting date: | | When did you quit: | | Home phone: | | Phone number at work: | </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that wording is consistent from one display to another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The title of a display should be identical to the menu option used to request that display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.7.4</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>213 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/14 Consistent Wording Across Displays</span></text>
</content>
<name>2.0/14</name>
<script></script>
</card>
card_58752.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For displayed data and labels, choose words carefully and then use them consistently. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent word usage is particularly important for technical terms. Standard terminology should be defined and documented in a glossary for </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Record A Change | | Record B Change | | Record C Change |</span><span class="style1"> (Bad) </span><span class="style8">| Update of Record A | | Record B Maintenance | | Change in Record C | </span><span class="style1">As a negative example, the word "screen" should not be used to mean "display frame" in one place, and "menu selection option" in another. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">The wording of displayed data and labels should incorporate familiar terms and the task-oriented jargon of the users, and avoid the unfamiliar jargon of designers and programmers. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When in doubt, pretest the meaning of words for prospective users to ensure that there is no ambiguity. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that each data display will provide needed context, recapitulating prior data as necessary so that a user does not have to rely on memory to interpret new data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When user information requirements cannot be determined in advance, it may be desirable to provide a separate display window as a "notepad" in which a user can preserve needed items by marking those to be saved. If data must be remembered from one display to another, display no more than four to six items. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 4.3.6Engel Granda 1975 § 2.3.15</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>210 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/11 Context for Displayed Data</span></text>
</content>
<name>2.0/11</name>
<script></script>
</card>
card_57976.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When protection of displayed data is essential, maintain computer control over the display and do not permit a user to change controlled items. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Never assume compliance with instructions by the user, who may attempt unwanted changes by mistake, or for curiosity, or to subvert the system. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.4.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/23 Display Format Protection1.4/7 Protected Labels6.2/3 Protecting Displayed Data6.3/2 Protection from Data Change</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>209 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/10 Protection of Displayed Data</span></text>
</content>
<name>2.0/10</name>
<script></script>
</card>
card_57640.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to change displayed data or enter new data when that is required by a task. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For some displays, of course, it is not desirable for users to change data, such as in operations monitoring (process control) displays, or displays permitting access to a protected data base. Some consistent formatting cue, perhaps different cursor shape or different initial cursor placement, should be provided to inform users when displayed data can or cannot be changed. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/6 Defined Display Areas for Data Entry1.3/2 Editing Capabilities During Text Entry6.2/4 Indicating Read-Only Displays</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>208 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/9 User Changes to Displayed Data</span></text>
</content>
<name>2.0/9</name>
<script></script>
</card>
card_57443.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to control the amount, format, and complexity of displayed data as necessary to meet task requirements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An experienced user may be able to deal with more complex displays than a novice. But a user experienced in one task may be a novice in another. Thus a range of display tailoring capabilities may be desirable for any particular task. Increasing the options for user control of data displays will complicate what a new user must learn about a system, and so will involve a trade-off against simplicity of user interface design. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 3.4.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/2 Only Necessary Data Displayed2.8/1 Flexible Design for Data Display2.7 -Display Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>207 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/8 User Control of Data Display</span></text>
</content>
<name>2.0/8</name>
<script></script>
</card>
card_57267.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that data display is consistent in word choice, format, and basic style with requirements for data and control entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When composing data and control entries, users will tend to mimic the vocabulary, formats, and word order used in computer displays, including displayed data, labels, error messages, and other forms of user guidance. When entry formats are consistent with display formats, users are more likely to compose an acceptable entry on their first try. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When the computer displays a list of current files, the names in that list should be in a format which would be recognized by the computer if they were part of a control entry; thus a user could mimic the displayed list if specifying a file for editing or mailing. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Good Whiteside Wixon Jones 1984Mooers 1983Zoltan-Ford 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/13 Wording Consistent with User Guidance4.0/18 Wording Consistent with Control Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>206 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/7 Display Consistent with Entry Requirements</span></text>
</content>
<name>2.0/7</name>
<script></script>
</card>
card_56834.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For any particular type of data display, maintain consistent format from one display to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When an item is missing from a standard format, display that item as a labeled blank rather than omitting it altogether. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When no specific user conventions have been established, adopt some consistent interface design standards for data display. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>204 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/5 Establishing Display Standards</span></text>
</content>
<name>2.0/5</name>
<script></script>
</card>
card_56509.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display data consistently with standards and conventions familiar to users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, if users work with metric units of measurement, do not display data in English units. Computer time records that are not in directly usable format should be converted for display, to a conventional 12-hour (AM/PM) clock or a 24-hour clock, in local time or whatever other time standard is appropriate to user needs. Calendar formats should follow user customs.</span><span class="style8"> (American calendar) (European calendar) S M T W T F S S 1 8 15 22 29 1 2 3 4 5 6 7 M 2 9 16 23 30 8 9 10 11 12 13 14 T 3 10 17 24 31 15 16 17 18 19 20 21 W 4 11 18 25 22 23 24 25 26 27 28 T 5 12 19 26 29 30 31 F 6 13 20 27 S 7 14 21 28 </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 3.4Engel Granda 1975 § 2.2.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/16 Familiar Wording</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>203 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/4 Data Display Consistent with User Conventions</span></text>
</content>
<name>2.0/4</name>
<script></script>
</card>
card_56304.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display data to users in directly usable form; do not make users convert displayed data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not require a user to transpose, compute, interpolate, or translate displayed data into other units, or refer to documentation to determine the meaning of displayed data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If altitude might be required in either meters or feet, then display both values. This recommendation applies to error messages and other forms of user guidance as well as to data displays. (Probably adequate) </span><span class="style8">| Character in NAME entry cannot be recognized. | </span><span class="style1">(Too cryptic) </span><span class="style8">| Error 459 in column 64. | </span></text>
<text>4.4/1 Guidance Information Always Available</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>202 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/3 Data Displayed in Usable Form</span></text>
</content>
<name>2.0/3</name>
<script></script>
</card>
card_55918.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Tailor displayed data to user needs, providing only necessary and immediately usable data for any transaction; do not overload displays with extraneous data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Display of extraneous data may confuse a user and hinder assimilation of needed information. When user information requirements cannot be exactly anticipated by the designer, allow users to tailor displays on line by controlling data selection (Section 2.7.1), data coverage within a display frame (Section 2.7.2), suppression of displayed data (Section 2.7.4), and data window overlay (Section 2.7.5). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| CODE DATA TYPE | | su = Summary | | d = Detailed list | | se = Sequences | </span><span class="style1">(Bad) </span><span class="style8">| CODE DATA TYPE DATE IMPLEMENTED | | su = Summary 5-17-82 | | d = Detailed list 7-14-82 | | se = Sequences 9-25-82 | </span></text>
<text>2.0/8 User Control of Data Display2.7/1 Flexible Display Control by User2.8/1 Flexible Design for Data Display4.0/5 Only Necessary Information Displayed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>201 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/2 Only Necessary Data Displayed</span></text>
</content>
<name>2.0/2</name>
<script></script>
</card>
card_55670.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that whatever data a user needs for any transaction will be available for display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The designer of user interface software must employ some method of task analysis (e.g., operational sequence diagrams) in order to determine a user's detailed information requirements for any transaction. If data requirements exceed a user's ability to assimilate information from the display, break the task into smaller steps. Prototype testing may be required to determine optimum data displays for critical tasks. A user should not have to remember data from one display to the next. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a minor example, header information should be retained or generated anew when a user is paging/scrolling data tables. As a negative example, even temporary loss of needed data, as might be caused by display blanking during automatic data update, is not acceptable in many design applications. </span></text>
<text>4.0/5 Only Necessary Information Displayed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>200 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA DISPLAY</span><span class="style20">2.0 General</span><span class="style21">2.0/1 Necessary Data Displayed</span></text>
</content>
<name>2.0/1</name>
<script></script>
</card>
card_55482.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data entry requirements may change, which is often the case, provide some means for users (or a system administrator) to make necessary changes to data entry functions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Data entry functions that may need to be changed are those represented in these guidelines, including changes to procedures, entry formats, data validation logic, and other associated data processing. Many of the preceding guidelines in this section imply a need for design flexibility. Much of that needed flexibility can be provided in initial interface design. Some guidelines, however, suggest a possible need for subsequent design change, and those guidelines are cited below. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/22 Storing User-Defined Formats1.4/25 Form Compatible with Source Documents1.7/1 Automatic Data Validation1.8/3 User Definition of Default Values1.8/8 Automatic Computation of Derived Data1.8/10 Automatic Entry of Redundant Data1.8/11 Automatic Cross-File Updating</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>199 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.9 Design Change</span><span class="style21">1.9/1 Flexible Design for Data Entry</span></text>
</content>
<name>1.9/1</name>
<script></script>
</card>
card_55093.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data must be entered in an organized hierarchic structure, in different sections and at different levels of increasing detail, provide computer aids for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">At the least, the computer should provide the user a schematic summary display of any defined data structure for general orientation, with its branches and levels labeled for convenient reference. When a user specifies any portion of the structure for data entry or editing, the computer should display that section of data appropriately labeled, and perhaps show in the display margin a diagram indicating what portion of the overall data structure is currently being displayed. When data at one level in a hierarchy are dependent on data entries at other (usually subordinate) levels, the computer should handle cross-level bookkeeping automatically, just as for cross-file updating. For entering hierarchic data, a user must specify where in the data structure any new data should be added. If the data structure is complex, it may help if the computer automatically prompts the user to make the appropriate data entries at different levels. If a user may need to change the data structure, then computer aids may be needed for that purpose as well as for data entry. The computer should bookkeep automatically any changing relations among the data in different sections that might result from changes to the overall data structure. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/31 Aids for Entering Hierarchic Data1.6/18 Aids for Entering Hierarchic Data2.4.8/11 Show Overview Position of Visible Section</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>198 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/12 Aids for Entering Hierarchic Data</span></text>
</content>
<name>1.8/12</name>
<script></script>
</card>
card_55038.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic cross-file updating whenever necessary, so that a user does not have to enter the same data twice. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If an aircraft has been assigned to a mission, the computer should automatically update both aircraft status and mission assignment files to indicate that commitment. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.1.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/1 Data Entered Only Once6.3/14 Automatic Data Generation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>197 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/11 Automatic Cross-File Updating</span></text>
</content>
<name>1.8/11</name>
<script></script>
</card>
card_54730.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If data are accessible to the computer that are logically related to other entries, program the computer to retrieve and enter those redundant data items automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When verification of previously entered data is required, ask users to review and confirm data items rather than re-enter them. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Redundant entry may be needed for resolving ambiguous entries, for user training, or for security (e.g., user identification). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, a user should not have to enter both an item name and identification code when either one defines the other. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/10 Automatic Entry of Redundant Data</span></text>
</content>
<name>1.8/10</name>
<script></script>
</card>
card_54382.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data entries made in one transaction are relevant to a subsequent transaction, program the computer to retrieve and display them for user review rather than requiring re-entry of those data. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.4.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/1 Data Entered Only Once6.3/13 Data Verification by User Review</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>195 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/9 User Review of Prior Entries</span></text>
</content>
<name>1.8/9</name>
<script></script>
</card>
card_54207.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic computation of derived data, so that a user does not have to calculate and enter any number that can be derived from data already accessible to the computer. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Statistical descriptors such as sums, means, etc., can all be derived automatically by appropriate software. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.1.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.3/14 Automatic Data Generation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>194 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/8 Automatic Computation of Derived Data</span></text>
</content>
<name>1.8/8</name>
<script></script>
</card>
card_53844.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For routine data that can be derived from existing computer records, program the computer to access and enter such data automatically. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Some data entry routines may be imposed in the interest of security, but at the risk of hindering a user in achieving effective task performance. Other means of ensuring data security should be considered. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, do not require a user to identify a work station in order to initiate a transaction, nor to include other routine data such as current date and transaction sequence codes. </span></text>
<text>6.1/1 Easy LOG-ON6.3/14 Automatic Data Generation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>193 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/7 Automatic Generation of Routine Data</span></text>
</content>
<name>1.8/7</name>
<script></script>
</card>
card_53524.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to replace any data entry default value with a different entry, without thereby changing the default definition for subsequent transactions. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.6.9</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>192 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/6 Temporary Replacement of Default Values</span></text>
</content>
<name>1.8/6</name>
<script></script>
</card>
card_53450.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users with some simple means to confirm acceptance of a displayed default value for entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Employ similar techniques when a user must review the accuracy of previously entered data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Simply tabbing past the default field may suffice. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/5 Easy Confirmation to Enter Default Values</span></text>
</content>
<name>1.8/5</name>
<script></script>
</card>
card_53059.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">On initiation of a data entry transaction, display currently defined default values in their appropriate data fields. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not expect users to remember them. It may be helpful to mark default values in some way to distinguish them from new data entries. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/4 Display of Default Values</span></text>
</content>
<name>1.8/4</name>
<script></script>
</card>
card_52971.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When interface designers cannot predict what default values will be helpful, permit users (or perhaps a system administrator) to define, change or remove default values for any data entry field. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.6.8</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>189 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/3 User Definition of Default Values</span></text>
</content>
<name>1.8/3</name>
<script></script>
</card>
card_52670.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a series of default values have been defined for a data entry sequence, allow a user to default all entries or to default until the next required entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Where a set of default values has been defined, a user may not wish to specify that each default value should be accepted for each data field individually. It might be quicker to accept the set of defaults by a single action. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>188 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/2 Defaults for Sequential Entries</span></text>
</content>
<name>1.8/2</name>
<script></script>
</card>
card_52392.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When likely default values can be defined for the data entries in a particular task, offer those default values to speed data entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>187 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.8 Other Data Processing</span><span class="style21">1.8/1 Default Values</span></text>
</content>
<name>1.8/1</name>
<script></script>
</card>
card_52139.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For novice users, consider providing optional item-by-item data validation within a multiple-entry transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This capability, which might be termed an "interim ENTER", may sometimes help a novice user who is uncertain about the requirements imposed on each data item. But item-by-item processing may slow skilled users. Providing such a capability as an optional feature would help novices without hindering more experienced users. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 6.3.9 7.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.3/10 Non-Disruptive Error Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>186 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/7 Optional Item-by-Item Validation</span></text>
</content>
<name>1.7/7</name>
<script></script>
</card>
card_51946.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In a repetitive data entry task, validate the data for one transaction and allow the user to correct errors before beginning another transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This is particularly important when the task requires transcription from source documents, so that a user can detect and correct entry errors while the relevant document is still at hand. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.5/12 Immediate Data Correction6.3/9 Immediate Error Correction</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>185 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/6 Timely Validation of Sequential Transactions</span></text>
</content>
<name>1.7/6</name>
<script></script>
</card>
card_51482.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user has deferred entry of required data but then requests processing of entries, signal that omission to the user and allow immediate entry of missing items or perhaps further deferral. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/5 Reminder of Deferred Entry</span></text>
</content>
<name>1.7/5</name>
<script></script>
</card>
card_51346.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user wishes to defer entry of a required data item, require the user to enter a special symbol in the data field to indicate that the item has been temporarily omitted rather than ignored. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/4 Deferral of Required Data Entry</span></text>
</content>
<name>1.7/4</name>
<script></script>
</card>
card_51019.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If data validation detects a probable error, display an error message to the user at the completion of data entry; do not interrupt an ongoing transaction. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.3/10 Non-Disruptive Error Messages</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>182 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/3 Non-Disruptive Error Messages</span></text>
</content>
<name>1.7/3</name>
<script></script>
</card>
card_50775.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that every possible correct data entry will be accepted and processed properly by the computer. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This guideline states the obvious, and might seem unnecessary except for occasional design lapses such as that cited in the example. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, on 1 June 1983, after several previous months of successful use, the computers controlling Massachusetts automobile emission inspections failed; it was discovered that they would not accept a "June" entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>181 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/2 Accepting Correct Entries</span></text>
</content>
<name>1.7/2</name>
<script></script>
</card>
card_50541.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide software for automatic data validation to check any item whose entry and/or correct format or content is required for subsequent data processing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not rely on a user always to make correct entries. Computer aids for checking data entries will improve accuracy. Some data entries, of course, may not need checking, or may not be susceptible to computer checking, such as free text entries in a COMMENT field. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a date is entered as "February 31", the computer should generate an error message asking for a revised entry. </span></text>
<text>6.3/17 Validating Data Changes6.3/18 Cross Validation of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>180 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.7 Data Validation</span><span class="style21">1.7/1 Automatic Data Validation</span></text>
</content>
<name>1.7/1</name>
<script></script>
</card>
card_50348.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When drawings are variations on a common theme, consider providing a computer model that will allow users to create particular instances by entering appropriate parameters. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Different kinds of models might be needed, including models based on geometric, surface, and solid relations, as well as even more complex logical models. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">An aerodynamic model might be invoked to help create (and evaluate) an aircraft wing design. For designing a workplace for human use, it might be helpful to store a body model from which the computer could draw automatically a sample user of any specified size percentile, and then move body parts of the displayed sample user to ensure that all controls are within reach. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where design rules have been previously defined, provide computer aids to complete automatically any details of graphic data entry covered by those rules. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The computer might automatically add dimensional annotation to drafted figures. When drawing or editing a polygon, the computer might automatically maintain closure if additional vertices are specified, rather than requiring the user to close the figure manually. In computer-aided design, if the flanges of connected components are designed with arcs of standard radius, then a user might draw those joints square and ask the computer to round them. A computer might create perspective drawings automatically from plan and elevation data, with hidden parts eliminated. In drawing flow charts, a computer might automatically add the arrow to a connecting line, depending upon the direction in which the line was drawn (or the sequence in which its points were designated). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Gardan Lucas 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6.1/6 Computer Derivation of Graphic Data</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When area coding is required, provide aids to allow users to fill an enclosed area with a selected attribute (color, shading or cross-hatching) by a simple specification action, rather than by having to trace over the area involved. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user might wish to shade the bars of a bar chart, or the wedges in a pie chart, or the various components of a drawn diagram or picture. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For many applications, it may suffice if a user can simply point at one of several displayed attributes (color patches, brightness levels, hatching patterns) and then point at the area to be filled. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In the special case when a drawn object can be created by the junction or disjunction of other graphic elements, provide computer aids for merging those elements by boolean combination. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This technique can represent the intersection of solid objects and also the result of drilling holes in an object. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In showing the junction of two objects comprising the components of some more complex object, a computer might calculate and draw their intersection, automatically dealing with overlapped data sets and concealed contours. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to designate a group of elements to which graphic editing operations will be applied in common. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Grouping elements might be a temporary action, intended for just a few successive editing operations, or it might be specified more permanently via some sort of "make group" command. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might carefully position two elements with respect to each other, and then wish to move both of them together while preserving their relative positions. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When users must create symmetric graphic elements, provide a means for specifying a reflection (mirror image) of existing elements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Many graphic displays contain symmetric figures where if one side has been drawn the other side might be created quickly as a reflected copy of the first, perhaps with some subsequent modification by the user. Users will need some means for specifying the desired reflection plane, which for practical purposes should probably be constrained to a choice between left-right and up-down reflection. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Gardan Lucas 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>174 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/14 Reflection of Elements</span></text>
</content>
<name>1.6.2/14</name>
<script></script>
</card>
card_48820.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When editing graphic data that depict objects, allow users to rotate a selected element on the display, in order to show it in different orientations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Rotation of a displayed element will usually prove easier than deleting an element and then recreating it from scratch in the desired orientation. A capability for rotating an element will aid initial data entry as well as any subsequent editing of graphic data. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to copy a selected graphic element in order to duplicate it elsewhere or create a repeating pattern. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Many graphic displays contain repeating elements; copying an element already created may prove quicker than redrawing that element from scratch. In creating patterns, a user will often need to specify a reference point in the original element and then specify where that point should be placed for each copy of that element. In some special applications, it might help to provide an optional kind of copying capability called "instancing", in which a user can choose to copy a graphic element from a stored template, and then all copies (or instances) will be changed automatically whenever that original template is changed. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In applications where users may create special symbols, provide a capability for drawing (or changing) a symbol in large scale, with automatic reduction by the computer to the needed size. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When drawing symbols in large scale, a rough sketch may suffice, requiring less dexterity from a user. The desirable degree of scale expansion will depend upon symbol complexity, and can probably be determined by testing. Some designers recommend a 20x20 grid to provide an enlarged pixel representation, on which a user can add or delete pixels to create a symbol. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Enlargement might aid in specifying shapes to be used for plotting points or for map symbols, or in designing icons or the letters in a font. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6/5 Zooming for Precise Positioning</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>171 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/11 Enlargement for Symbol Drawing</span></text>
</content>
<name>1.6.2/11</name>
<script></script>
</card>
card_48041.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When editing graphic data, allow users to change the size of any selected element on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Scaling displayed elements to different sizes, expanding or shrinking them, will usually prove easier than deleting an element and then recreating it from scratch in the desired size. A capability for changing the scale of a displayed element will aid initial data entry as well as any subsequent editing of graphic data. Depending on the application, it may be helpful to provide a continuous sizing capability, or else incremental sizing to various defined scales. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In applications requiring a general capability for drawing figures, provide a choice of methods for specifying graphic elements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">These examples are from the demanding realm of computer-aided design. Simpler kinds of graphic entry may not require such capabilities. In the use of various figure-drawing aids, it may be helpful if the computer can provide step-by-step prompts for each procedure, e.g., "Now indicate center point", "Now indicate radius", etc. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A straight line might usually be created by specifying two points, but sometimes it might be easier to specify one point plus a constraint that the line be parallel (perpendicular, tangent) to some other line. A circle might usually be created by specifying its center and a point on its circumference; but sometimes it might be easier to specify a circle by other means -- e.g., by two ends of its diameter, or by three points on its circumference, or by its center plus a constraint that it be tangent to some other figure, or by inscribing it within a square. An ellipse might usually be created by specifying two foci and a point on its perimeter, but sometimes it might be easier to specify its center and draw its long and short axes, or it might be inscribed within a rectangle. A regular polygon might usually be created by specifying the end points of one edge and the number of sides, but it also might be specified by its center and one vertex and the number of its sides. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Gardan Lucas 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>169 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/9 Alternative Methods for Drawing Figures</span></text>
</content>
<name>1.6.2/9</name>
<script></script>
</card>
card_47551.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must draw figures, provide computer aids for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Much graphic construction can either be aided in some way (by templates, tracing techniques, grid gravity, etc.), or can employ machine generation of computed or stored forms, often followed by user editing of those forms. A great many different figures can be created by combining simple elements or by specifying geometric parameters (e.g., conic sections). Computer aids that allow such shortcuts can speed figure drawing and make the process more accurate. In some applications, such as constructing organization charts, figures may repeat a number of standard elements. In such cases computer aids can be provided to make the production of figures almost routine. Some capability for freehand drawing may be needed, particularly in the creation of graphic art, but freehand drawing will not provide sufficient precision for many applications. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might select from a stored set of standard forms -- rectangles, circles, etc. -- and edit those to create figures or the component elements of figures, rather than having to draw each figure from scratch. Computer logic might be provided to allow a user to create a rectangle simply by designating two opposite corners, or a circle by first specifying its center and then any point on its circumference, with rubberbanding to show the result of any current selection. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">For precise drawing, allow users to draw lines by specifying their geometric relations with other lines. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In computer-aided design, a user might wish to create a new line by declaring it parallel with (or perpendicular to) an existing line. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>167 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/7 Specifying Line Relations</span></text>
</content>
<name>1.6.2/7</name>
<script></script>
</card>
card_46958.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic elements are created with vertical and horizontal lines, allow users to specify appropriate constraints during line drawing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Here computer logic is invoked to interpret casual freehand gestures by a user as if they were carefully drawn -- the electronic equivalent of a draftsman's T-square. Thus a roughly vertical motion by a user could create an exactly vertical line in computer storage and display. In applications where orthogonal lines predominate, it may be helpful to make constrained drawing the norm, while allowing users to specify free-form drawing as an exception. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982Gardan Lucas 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>166 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/6 Constraint for Vertical and Horizontal Lines</span></text>
</content>
<name>1.6.2/6</name>
<script></script>
</card>
card_46804.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a reference grid is displayed to aid graphic data entry, allow users to change the grid intervals in either or both directions. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For different applications, a user may wish to work with a fine grid or a coarse grid, depending on the quantizing interval of the data being plotted. Some designers recommend a standard grid resolution of 1/20 of graph height or width, but such a standard will not be optimum for every application. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic elements are created with vertical and horizontal alignment, provide a reference grid that can be requested by a user to aid that alignment. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A reference grid might be displayed merely as a visual aid. In some instances, however, where repeated graphic elements must be aligned in regular fashion, it may be helpful to use a grid to position graphic elements automatically at its intersections. An example might be the construction of organization charts with repeating rows of boxes connected by line segments. "Grid gravity" might be provided automatically during graphic entry, based on "gravity field" connection of drawn lines to grid points, or might be invoked as a separate editing command by a user. A grid suitable for aiding data entry may not prove equally helpful for subsequent interpretation of data on the completed display. Therefore, after a graphic image has been composed, the user should decide whether or not to include the reference grid in the finished display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace Chan 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.1/11 Aids for Scale Interpolation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>164 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/4 Grid Reference for Alignment</span></text>
</content>
<name>1.6.2/4</name>
<script></script>
</card>
card_46196.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When line segments must join or intersect, which is true in most drawing, provide computer logic to aid such connection. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">An effective computer logic to aid line connection is to provide a so-called "gravity field" surrounding each line segment, so that if a line-drawing cursor is moved within that field the cursor's new line will be extended automatically to intersect the already-displayed line. Note that a "gravity field" need not itself be displayed; users will soon learn to infer its extent by its effect in aiding cursor placement. Because users often seek to join line segments at their ends, it may help to enlarge the zone of attraction at the end of each displayed line to facilitate such end-to-end connection. The concept of "gravity field" can also be used to align drawn line segments with points in a reference grid, as well as with each other. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982Gardan Lucas 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>163 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/3 Aiding Line Connection</span></text>
</content>
<name>1.6.2/3</name>
<script></script>
</card>
card_46035.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When lines must be drawn at arbitrary positions, lengths and angles, provide a rubberbanding capability, in which the computer displays a tentative line extending from a designated start point to whatever is the currently proposed end point. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This technique permits users to enter or change a line segment rapidly and with confidence by designating its starting point and then simply moving the cursor to the desired end-point, thus placing the "rubberband" line in its intended position. A similar capability should be provided to aid entry/editing of specified outline figures. A rectangle might be rubberbanded by fixing one corner and moving the opposite corner. A circle might be rubberbanded to desired size by fixing its center and changing the extension of its radius. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982Foley Wallace Chan 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>162 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.2 Graphics - Drawing</span><span class="style21">1.6.2/2 Rubberbanding</span></text>
</content>
<name>1.6.2/2</name>
<script></script>
</card>
card_45603.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When line drawing is required, provide users with aids for drawing straight line segments. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some applications may require drawing continuous lines freehand. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic data can be derived from data already available in the computer, provide machine aids for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The machine capacity for generating graphic data by computation will far exceed a user's capabilities in both speed and accuracy. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A computer might fit a smoothed curve through plotted data values, filter out points when drawing a densely defined curve, rescale graphs, invert graphs by exchanging X- and Y-values, convert graphs to show cumulative curves, calculate and display various statistical measures of data distribution, produce a contour plot from gridded data with linear interpolation, plot map contours from latitude-longitude coordinates, calculate bearings, distances, and areas on maps, plot perspective views of objects defined in plan views, plot specified cross-sections of displayed objects, calculate a parts list for a designed assembly, identify critical paths and float time in network scheduling charts, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.8/8 Automatic Computation of Derived Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>160 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.1 Graphics - Plotting Data</span><span class="style21">1.6.1/6 Computer Derivation of Graphic Data</span></text>
</content>
<name>1.6.1/6</name>
<script></script>
</card>
card_45130.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide computer aids to help users specify appropriate scales for graphic data entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The computer should handle scaling automatically, subject to review and change by a user. The computer might provide a general template for the plotting scale and prompt the user as necessary to define the scale more exactly, including specification of the origin, linear or logarithmic axes, scale intervals, minimum and maximum values, and labels for axes. In the process of defining scales the computer might impose rules to ensure that the resulting graphic displays are designed to permit effective information assimilation by their users, e.g., displaying scales with conventional direction, so that numbers increase in value from left to right, or from bottom to top. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace 1974</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.4.1/1 Scaling Conventions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>159 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.1 Graphics - Plotting Data</span><span class="style21">1.6.1/5 Aids for Scaling</span></text>
</content>
<name>1.6.1/5</name>
<script></script>
</card>
card_44847.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphs must be constructed for data plotting, provide computer aids for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Computer aids for graph construction should be designed to allow flexibility in their use. A user should be allowed to position labels and other graphic elements at will, except where operational requirements may impose fixed formats. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Construction aids might include stored templates of different kinds of graphs, prompts to guide users in the definition of scale axes, and aids for format control such as automatic centering of axis labels if requested by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>158 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.1 Graphics - Plotting Data</span><span class="style21">1.6.1/4 Aids for Graph Construction</span></text>
</content>
<name>1.6.1/4</name>
<script></script>
</card>
card_44661.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic data must be plotted in predefined standard formats, provide templates or skeletal displays for those formats to aid data entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications, it may help to provide flexibility so that general prestored formats can be modified by a user and then saved for subsequent use. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Sample displays might be stored in the computer to aid in creating standard graphs such as bar graphs, or standard diagrams such as organization charts, or page layouts for typesetting, or maps drawn to different scales or with different projections. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automated plotting of computer-stored data at user request, with provision for subsequent editing by a user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In many applications, data intended for graphic display will already be stored in the computer. In such cases a user might specify the graphic format required and edit elements in the resulting display output, without actually having to re-enter the data. When users do have to enter data for graphic display, they might choose form filling or tabular entry for efficiency in the initial input of data and then invoke graphic capabilities for subsequent data editing. In either case, it is important that previously entered data should be accessible for graphic processing. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A computer might plot the data values from two arrays in a line graph, or three-dimensional data in XYZ coordinates. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.8/7 Automatic Generation of Routine Data1.8/8 Automatic Computation of Derived Data</text>
<text><span class="style10">Γêå Statement</span><span class="style1">When complex graphic data must be entered quickly, provide computer aids to automate that process. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users can create simple graphics or edit stored graphic material fairly quickly, but they can create complex graphic displays only much more slowly. A variety of computer aids can be provided to help enter graphic data. Entry of detailed drawings and/or photographic imagery can be accomplished via a video camera and high-resolution digitizer, perhaps with facilities for a user to edit that process. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Prestored geographic data and background maps, along with automated entry ("posting") of flight plan data and track data, will permit fast and accurate generation of graphic displays for air traffic control, far beyond the capabilities of manual entry by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>155 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6.1 Graphics - Plotting Data</span><span class="style21">1.6.1/1 Automated Data Plotting</span></text>
</content>
<name>1.6.1/1</name>
<script></script>
</card>
card_43893.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic data represent relations among real objects, provide appropriate computer logic based on models of physical probability to validate data entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If inconsistencies of data entry cannot be resolved immediately, the computer might keep track of unresolved questions pending receipt of further data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If data indicate that a military land unit has been reported in the middle of a lake, the computer should call that discrepancy to the user's attention. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.7/1 Automatic Data Validation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>154 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/19 Automatic Data Validation</span></text>
</content>
<name>1.6/19</name>
<script></script>
</card>
card_43625.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic data must be entered in an organized hierarchic structure, in different sections and at different levels of increasing detail, provide computer aids for that purpose. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For entering map data, a user might have to specify different levels of data storage for a city's name and location, its municipal boundaries, its major road patterns, its street names and house numbers, etc.; computer aids could help that process. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/31 Aids for Entering Hierarchic Data1.8/12 Aids for Entering Hierarchic Data2.4/15 Zooming for Display Expansion</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>153 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/18 Aids for Entering Hierarchic Data</span></text>
</content>
<name>1.6/18</name>
<script></script>
</card>
card_43394.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic registration or alignment of computer-generated graphic data, so that variable data are shown properly with respect to fixed background or map data at any display scale. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When users are required to enter data via some separate device such as a graphics tablet, rather than directly on the display surface, it may be necessary for a user to participate in some computer-prompted procedure for ensuring data registration. Such a procedure may prove error-prone, however, and should be considered an undesirable expedient. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>152 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/17 Automatic Data Registration</span></text>
</content>
<name>1.6/17</name>
<script></script>
</card>
card_43139.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to name graphic displays or designated elements, in order to aid storage and retrieval or manipulation during graphic data entry/editing; and provide means for a user to review a current "catalog" of named elements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Standard displays and graphic components might be assigned names automatically by the computer, but users will still need a capability to assign their own names to interim versions of displays in creation, or to various elements of those displays. In either case, users may forget what names have been assigned; some "catalog" of currently named elements will serve as a helpful reminder. For currently displayed material, pointing may be more convenient than naming for the designation of selected elements; but names will certainly aid the retrieval of stored material. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Gardan Lucas 1984</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>151 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/16 Naming Displays and Elements</span></text>
</content>
<name>1.6/16</name>
<script></script>
</card>
card_42958.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide easy means for saving and retrieving graphic displays or their component elements at different stages in their creation. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should not have to create a graphic image more than once. Once a graphic element has been created, a user should be able to save it for possible re-use. As a protective measure, a user might wish to save different versions of a graphic display at successive stages during its creation, in order to return to an earlier state if later results seem unsatisfactory. During creation, the elements added to a graphic display can be interrelated in complex ways, and thus stepwise deletion of unwanted elements could prove a difficult process. An UNDO command might be helpful for deleting some of the most recently added elements. But storage and subsequent retrieval of interim versions of the display may be more helpful for a foresighted user. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>150 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/15 Easy Storage and Retrieval</span></text>
</content>
<name>1.6/15</name>
<script></script>
</card>
card_42570.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When editing graphic data, allow users to change display attributes by whatever means were used to select those attributes in the first place. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Many editing changes will be made during data entry, rather than as separate later actions, and thus it is important that entry and editing actions be consistent. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If line type is selected initially from a menu of displayed attributes, then changing a line type should also be accomplished via menu selection. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>149 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/14 Consistent Method for Attribute Selection</span></text>
</content>
<name>1.6/14</name>
<script></script>
</card>
card_42468.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When entering or editing graphic data, allow users to change display attributes -- e.g., line type, cross-hatching, color -- for selected graphic elements. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If it is easy to change attributes, reversing earlier data entry decisions, then the process of composing graphic displays will be generally easier. Another approach to changing an attribute might be to rely on general editing capabilities, i.e., to delete the element in question (perhaps using an UNDO command for an element just created) and then redraw it. But a capability for specifying attribute change directly, without element deletion and reentry, will often be helpful. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a figure was created initially with dashed lines, then a user should be able to select the figure, or portions of it, and change the dashed lines to solid lines by specifying that alternative attribute. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6/6 Selecting Graphic Elements</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>148 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/13 Changing Attributes</span></text>
</content>
<name>1.6/13</name>
<script></script>
</card>
card_42049.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">During graphic data entry/editing, display the selected attributes that will affect current actions for ready reference by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users may forget what options have been chosen. Displayed reminders will be particularly important in situations where the consequences of a mistaken user action are difficult to reverse, e.g., where it may be hard to erase a wrongly drawn line. In some applications, display cues may not be adequate to convey attribute information completely. There may not be sufficient room on the display. Or the attributes may derive from underlying models whose characteristics are too complex for simple display representation. In such cases, users should be able to request auxiliary display of such information to determine the operative context for current actions. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When graphic attributes -- plotting symbols, character size, line type, color, etc. -- are chosen from displayed menus, it might suffice to highlight the currently selected menu options; alternatively, current selections might be shown in some sort of "reminder" window. A few attributes might be shown by the displayed cursor, i.e., by changing cursor shape, size or color depending upon current attribute selections. If rubberbanding is provided to aid line drawing, then that process itself would show the currently selected line type. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/12 Displaying Current Attributes</span></text>
</content>
<name>1.6/12</name>
<script></script>
</card>
card_41875.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If users may select colors as an attribute of graphic elements, allow them to specify colors directly by pointing at displayed samples, rather than requiring them to name the colors. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If many colors are available, users with normal vision can choose from displayed samples more reliably than from a list of color names. For color-blind users, however, it might be helpful to add names/labels to the displayed samples. For more elaborate graphic art, it may be helpful to allow users to mix their own colors by sequential selection (i.e., cursor placement), either in a displayed palette or directly in a graphic image. Such color mixing could permit user control of saturation, brightness, and opacity/transparency, as well as hues. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If only a few colors are available, their names can probably be used reliably. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>146 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/11 Selecting Colors</span></text>
</content>
<name>1.6/11</name>
<script></script>
</card>
card_41683.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">During graphic data entry, allow users to specify attributes for displayed elements -- e.g., text font, plotting symbol, line type, color -- by selecting from displayed samples illustrating the available options. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A display of available attributes will serve as a helpful reminder to the user, and will eliminate the need to assign distinctive verbal labels to the various options. Samples of some attributes may be difficult to display. In complex graphics, for example, specification of line type might involve selection among "brushes", each of which has a "tip" defining the size and shape of the drawing area (a group of pixels) that the user can manipulate. Brushes might have squared tips to draw sharp lines, or rounded tips to draw lines with softer edges. By analogy with artistic painting, a "smear" brush might be provided to average or blend colors along its path. Selective erasure might be accomplished with a brush applying (returning to) the color of the display background. In most applications, the current selection of data attributes should remain in effect until a new selection is made. In some cases, e.g., following selection of an "erase" attribute, it may help the user if a selected attribute reverts automatically to a default value at the completion of a transaction sequence. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For line drawing a user might select from displayed samples of thick or thin, solid or broken, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>145 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/10 Selecting from Displayed Attributes</span></text>
</content>
<name>1.6/10</name>
<script></script>
</card>
card_41449.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When editing graphic data, allow users to delete selected elements from the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Deletion/erasure will help when mistakes are made during data entry, as well as in any subsequent editing of graphic data. Deletion should be implemented as a reversible action. A general UNDO capability might suffice to reverse deletions. A more extended reversibility might be provided by saving deleted elements in a computer scrap basket from which they can be retrieved any time during a work session in case a deletion is discovered to be a mistake. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>144 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/9 Deleting Elements</span></text>
</content>
<name>1.6/9</name>
<script></script>
</card>
card_40981.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When editing graphic data, allow users to reposition selected elements on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Repositioning displayed elements, whether done by "dragging" or "cut-and-paste", will usually prove easier than deleting an element and then recreating it from scratch in the desired location. A capability for moving elements will aid initial data entry as well as any subsequent editing of graphic data. If an element is moved visibly by dragging across the display, it is probably not necessary to depict it in complete detail in all of its intermediate positions. It might suffice to show it in simplified outline until its new position has been confirmed by the user (or perhaps until it remains in one position for a fixed interval of time), at which point its details could be filled in again by the computer. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/23 Moving Text</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>143 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/8 Changing Position (Translation)</span></text>
</content>
<name>1.6/8</name>
<script></script>
</card>
card_40891.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user has selected (i.e., pointed at) a displayed graphic element, highlight that element in some way so that the user can anticipate the consequences of any proposed action involving that selection. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A dotted border might be displayed around a selected element, or perhaps a selected element might be displayed with video inversion to distinguish it from other elements. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users some means for designating and selecting displayed graphic elements for manipulation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Designation might be by pointing, in the case of a discrete element, or might require some sort of outlining action to delineate portions of a complex figure. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/5 Natural Units of Text</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>141 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/6 Selecting Graphic Elements</span></text>
</content>
<name>1.6/6</name>
<script></script>
</card>
card_40263.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data entry requires exact placement of graphic elements, users should be allowed to request expansion of the critical display area ("zooming") to make the positioning task easier. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace 1974</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6.2/11 Enlargement for Symbol Drawing2.4/15 Zooming for Display Expansion</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>140 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/5 Zooming for Precise Positioning</span></text>
</content>
<name>1.6/5</name>
<script></script>
</card>
card_40043.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For most graphics data entry, pointing should be a dual action, first positioning a cursor at a desired position, and then confirming that position to the computer. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">During graphics data entry, a cursor will almost always be somewhere on the display, but not necessarily at a location intended by the user. In effect, a user needs some way to move the cursor around and some separate action to signal the computer when its position should be recorded. An interesting case of position confirmation is "rubberbanding", which is a technique to aid line drawing. With rubberbanding, a user can designate the starting point for a line, then move the cursor to various possible end points while the computer continuously shows the line that would result if that end point were confirmed by the user. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">An exception to this recommendation would be the freehand drawing of continuous lines ("path specification"), where a computer must store and display a series of cursor positions as they are input by the user; when the user initiates such a line-drawing sequence, a new data point might be recorded automatically whenever the cursor has been moved a certain distance (e.g., 1 mm) or when a certain time has elapsed (e.g., 0.5 s). </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Provide users an easy, accurate means of positioning a displayed cursor to point at different display elements and/or display locations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Cursor positioning is a frequent user action during graphic data entry; an easy means for controlling cursor movement will be essential for efficient performance. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/7 Responsive Cursor Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>138 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/3 Easy Cursor Positioning</span></text>
</content>
<name>1.6/3</name>
<script></script>
</card>
card_39434.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Indicate the current cursor position by displaying some distinctive cursor symbol at that point. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The cursor may take various forms on a graphics display. Many designers recommend a plus-sign for this purpose, representing abbreviated cross-hairs whose intersection can mark a position with reasonable precision. In some applications it may help to extend those cross-hairs the full height and width of the display. In some applications it may help to display a cursor incorporating the current values of various attributes (color, size, etc.) that can be selected by a user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace Chan 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/1 Distinctive Cursor1.6/12 Displaying Current Attributes</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>137 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/2 Distinctive Cursor</span></text>
</content>
<name>1.6/2</name>
<script></script>
</card>
card_39342.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When graphic data entry involves frequent pointing on a display surface, design the user interface so that actions for display control and sequence control are also accomplished by pointing, in order to minimize shifts from one entry device to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation implies extensive use of menus in the margins of a graphic display to permit direct selection of data attributes and control options by pointing. If screen capacity is too limited to permit simultaneous display of both graphic data and menus, then the designer might provide temporary superposition of menu windows on displayed data, or might provide some separate display device to show current options for control entry. Control entry via keyboard and/or function keys will be less satisfactory. If pointing is performed on some separate input device, such as a stylus on a digitizing tablet, then associated control actions should also be implemented via that device. For graphics software, a pointing action by a user can accomplish several different logical functions: specifying a displayed element ("pick" function); selecting a system-defined object, attribute or action ("button" or "choice" function); or indicating a location in the conceptual drawing space ("locator" function). A designer must distinguish among these functions, although most users will not. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Alphabetic entry for titles, labels, and other annotation of graphic displays will be accomplished more quickly by conventional keyboard input than by pointing. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In drawing a flow chart, a user should be able to link predecessor and successor elements directly by pointing at them, or by drawing lines between them, rather than by separately keyed entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace 1974Foley Van Dam 1982Foley Wallace Chan 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/5 Single Method for Entering Data1.1 Position Designation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>136 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.6 Graphics</span><span class="style21">1.6/1 Pointing</span></text>
</content>
<name>1.6/1</name>
<script></script>
</card>
card_38985.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For long tables, those with many rows, provide some extra visual cue to help a user scan a row accurately across columns. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Visual aids for scanning rows are probably needed more when a user is reviewing and changing displayed data than for initial data entry. Such aids should be provided consistently, however, so that display formats for both data entry and review will be compatible. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A blank line might be inserted after every fifth row; or perhaps adding dots between columns in every fifth row might suffice. As an alternative, provide a displayed ruler which a user can move from one row to another. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/14 Row Scanning Cues</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>135 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/10 Row Scanning Cues</span></text>
</content>
<name>1.5/10</name>
<script></script>
</card>
card_38881.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For entry of tabular data, when entries are frequently repeated, provide users with some easy means to copy duplicated data. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A DITTO capability will speed data entry, and should prove more accurate than requiring users to rekey duplicated data. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Perhaps a DITTO key might be provided. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>134 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/9 Aiding Entry of Duplicative Data</span></text>
</content>
<name>1.5/9</name>
<script></script>
</card>
card_38485.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user must enter numeric values that will later be displayed, maintain all significant zeros; zeros should not be arbitrarily removed after a decimal point if they affect the meaning of the number in terms of significant digits. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.4.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.3/17 Maintaining Significant Zeros</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>133 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/8 Maintaining Significant Zeros</span></text>
</content>
<name>1.5/8</name>
<script></script>
</card>
card_38190.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to make numeric entries in tables without concern for justification; the computer should right-justify integers, or else justify with respect to a decimal point if present. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A dollars-and-cents entry made at the beginning of a field </span><span class="style8">| 14.37 __ __ |</span><span class="style1"> should automatically be justified to the right </span><span class="style8">| __ __ 14.37 |</span><span class="style1"> when later displayed. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.8.10</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>132 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/7 Justification of Numeric Entries</span></text>
</content>
<name>1.5/7</name>
<script></script>
</card>
card_38107.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic justification of tabular data entries; a user should not have to enter blanks or other extraneous formatting characters to achieve proper justification. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, if a user enters "56" in a field four characters long, the system should not interpret "56 __ __" as "5600". </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.2.5</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>131 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/6 Automatic Justification of Entries</span></text>
</content>
<name>1.5/6</name>
<script></script>
</card>
card_37796.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">During tabular data entry, allow users to tab directly from one data field to the next, so that the cursor can move freely up and down a column (i.e., across rows). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.8.4.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>130 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/5 Tabbing within Columns</span></text>
</content>
<name>1.5/5</name>
<script></script>
</card>
card_37410.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">During tabular data entry, allow users to tab directly from one data field to the next, so that the cursor can move freely back and forth within a row (i.e., across columns). </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.8.4.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>129 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/4 Tabbing within Rows</span></text>
</content>
<name>1.5/4</name>
<script></script>
</card>
card_37130.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that column headers and row labels are worded informatively, so that they will help guide data entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/11 Clear Data Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>128 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/3 Informative Labels</span></text>
</content>
<name>1.5/3</name>
<script></script>
</card>
card_37086.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design distinctive formats for column headers and row labels, so that users can distinguish them from data entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.0/8 Distinctive Format for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>127 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/2 Distinctive Labels</span></text>
</content>
<name>1.5/2</name>
<script></script>
</card>
card_36767.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When sets of data items must be entered sequentially, in a repetitive series, provide a tabular display format where data sets can be keyed row by row. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Row-by-row entry facilitates comparison of related data items, and permits potential use of a DITTO key for easy duplication of repeated entries. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When the items in each data set exceed the capacity of a single row, tabular entry will usually not be desirable, unless there is a simple means for horizontal scrolling. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.8.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.7.2/4 Labels for Multipage Tables</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>126 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.5 Tables</span><span class="style21">1.5/1 Tables for Related Data Sets</span></text>
</content>
<name>1.5/1</name>
<script></script>
</card>
card_36211.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a form for data entry is displayed, the computer should place the cursor automatically at the beginning of the first entry field. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">If a data form is regenerated following an entry error, the cursor should be placed in the first field in which an error has been detected. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If no source document or external information is involved, then design forms so that data items are ordered in the sequence in which a user will think of them. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The software designer will need to work with prospective system users to determine what represents a logical sequence of data entries. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 4.8.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data2.5/14 Data Grouped by Sequence of Use</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>124 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/27 Data Items in Logical Order</span></text>
</content>
<name>1.4/27</name>
<script></script>
</card>
card_35723.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When designing displays for form-filling data entry, minimize user actions required for cursor movement from one field to the next. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Placing all required fields before any optional fields will sometimes make data entry more efficient. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.1.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/22 Easy Cursor Movement to Data Fields1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>123 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/26 Minimal Cursor Positioning</span></text>
</content>
<name>1.4/26</name>
<script></script>
</card>
card_35540.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data entry involves transcription from source documents, ensure that form-filling displays match (or are compatible with) those documents, in terms of item ordering, data grouping, etc. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If paper forms are not optimal for data entry, consider revising the layout of the paper form. If data entries must follow an arbitrary sequence of external information (e.g., keying telephoned reservation data), employ some form of command language dialogue instead of form filling, to identify each item as it is entered so that the user does not have to remember and re-order items. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data2.5/1 Consistent Format2.5/14 Data Grouped by Sequence of Use3.1.1/4 Sequence Compatible with Source Documents4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>122 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/25 Form Compatible with Source Documents</span></text>
</content>
<name>1.4/25</name>
<script></script>
</card>
card_35204.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When forms are used for reviewing displayed data as well as for data entry, make the form for data entry compatible with that for display output; use the same item labels and ordering for both. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When a display format optimized for data entry seems unsuited for data display, or vice versa, some compromise format should be designed, taking into account the relative functional importance of data entry and data review in the user's task. </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.3.1.1.a</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data2.2/12 Form Compatible for Data Entry and Display2.5/1 Consistent Format4.0/6 Consistent Display Format</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>121 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/24 Form Compatible for Data Entry and Display</span></text>
</content>
<name>1.4/24</name>
<script></script>
</card>
card_34984.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When alternative measurement units are acceptable, provide space in the data field so that a user can designate the units actually entered. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| DISTANCE: __ __ __ __ (MI/KM) __ __ | </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data4.0/11 Clear Data Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>120 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/23 Alternative Units of Measurement</span></text>
</content>
<name>1.4/23</name>
<script></script>
</card>
card_34654.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Employ units of measurement that are familiar to the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If data must be converted to unfamiliar units, the computer should handle that automatically. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| SPEED LIMIT: __ __ miles per hour |</span><span class="style1"> (Bad) </span><span class="style8">| SPEED LIMIT: __ __ feet per second | </span><span class="style1">(Good) </span><span class="style8">| FUEL USE: __ __.__ miles per gallon | </span><span class="style1">(Bad) </span><span class="style8">| FUEL USE: .__ __ gallons per minute | </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data4.0/17 Task-Oriented Wording</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>119 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/22 Familiar Units of Measurement</span></text>
</content>
<name>1.4/22</name>
<script></script>
</card>
card_34409.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a measurement unit is consistently associated with a particular data field, include that unit as part of the field label rather than requiring a user to enter it. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| COST: $ __ __ __ __ | | SPEED (MPH): __ __ __ | </span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data2.2/10 Labeling Units of Measurement4.0/11 Clear Data Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>118 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/21 Labeling Units of Measurement</span></text>
</content>
<name>1.4/21</name>
<script></script>
</card>
card_34072.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Include in a field label additional cueing of data format when that seems helpful. </span><span class="style10">ΓêåΓêå Example</span><span class="style1"></span><span class="style8">| DATE (MM/DD/YY): __ __/__ __/__ __ | </span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data4.0/11 Clear Data Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>117 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/20 Data Format Cueing in Labels</span></text>
</content>
<name>1.4/20</name>
<script></script>
</card>
card_34011.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In labeling data fields, employ descriptive wording, or else standard, predefined terms, codes and/or abbreviations; avoid arbitrary codes. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Do not create new jargon. If in doubt, pretest all proposed wording with a sample of qualified users. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Employ descriptive labels such as STANDARD and MODIFIED, rather than abstract codes such as SET A and SET B; MALE and FEMALE, rather than GROUP 1 and GROUP 2. (Good) </span><span class="style8">| WEEK: __ MONTH: __ __ YEAR: __ __ | | | | SOCIAL SECURITY NO: __ __ __ - __ __ - __ __ __ __ | </span><span class="style1">(Bad) </span><span class="style8">| DATECODE: __ __ __ __ __ | | | | SSAN: __ __ __ __ __ __ __ __ __ | </span><span class="style1">See sample displays in section 1.4/1. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">The label for each entry field should end with a special symbol, signifying that an entry may be made. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Choose a symbol that can be reserved exclusively for prompting user entries, or at least is rarely used for any other purpose. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A colon is recommended for this purpose, as </span><span class="style8">| NAME: __ __ __ __ __ __ __ __ __ __ __ | </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.5</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data4.4/15 Cues for Prompting Data Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>115 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/18 Label Punctuation as Entry Cue</span></text>
</content>
<name>1.4/18</name>
<script></script>
</card>
card_33504.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data fields are distributed across a display, adopt a consistent format for relating labels to delineated entry areas. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such consistent practice will help the user distinguish labels from data in distributed displays. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The label might always be to the left of the field; or the label might always be immediately above and left-justified with the beginning of the field. </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data4.0/7 Consistent Format for User Guidance</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>114 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/17 Consistent Label Format</span></text>
</content>
<name>1.4/17</name>
<script></script>
</card>
card_33068.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Make labels for data fields distinctive, so that they will not be readily confused with data entries, labeled control options, guidance messages, or other displayed material. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Labels might be displayed in capital letters always followed by a colon. Or labels might be displayed in dim characters, with data entries brighter. See sample displays in this section. </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take explicit keying ("tabbing") action to move from one data entry field to the next; the computer should not provide such tabbing automatically. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic tabbing may cause cascading of errors, if a skilled typist keys a series of items without looking at the display and has accidentally overrun one of the earlier data fields. An acceptable solution here is to design each field to end with an extra (blank) character space; software should be designed to prevent keying into a blank space, and an auditory signal should be provided to alert the user when that is attempted. This will permit consistent use of tab keying by the user to move accurately from one field to the next, even for touch typists. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.1/22 Easy Cursor Movement to Data Fields1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>112 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/15 Explicit Tabbing to Data Fields</span></text>
</content>
<name>1.4/15</name>
<script></script>
</card>
card_32558.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When item length is variable, provide automatic justification in computer processing; a user should not have to justify an entry either right or left. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a data entry is shorter than its field length, its position when entered in that field should not matter. The computer can impose its own justification rules when storing and subsequently displaying such data for review. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Assuming field delineation by underscore, the following entries should all be considered equivalent </span><span class="style8">| Address: 40 Dalton Road_______ | | Address: _______40 Dalton Road | | Address: ___40 Dalton Road____ | </span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.2.2Engel Granda 1975 § 6.3.2</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>111 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/14 Automatic Justification of Variable-Length Entries</span></text>
</content>
<name>1.4/14</name>
<script></script>
</card>
card_32436.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When item length is variable, so that a data entry does not completely replace the markers in a field, ignore any remaining field markers in computer processing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should not be expected to erase any field markers. Extra markers should not be processed as part of a data entry if they are not erased. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>110 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/13 Field Markers Not Entered with Data</span></text>
</content>
<name>1.4/13</name>
<script></script>
</card>
card_32126.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In designing form displays, distinguish clearly and consistently between required and optional entry fields. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Field delineation cues may be used for this purpose, perhaps a broken underscore to indicate required entries and a dotted underscore to indicate optional entries, as </span><span class="style8">| LICENSE NUMBER: __ __ __ __ __ __ | | | | MAKE: . . . . . . . . . . . . . . | | | | YEAR/MODEL: . . . . . . . . . . . |</span><span class="style1">Alternatively, it might be preferable to distinguish required versus optional entry fields by coding their labels, perhaps displaying in parentheses the labels of optional fields. </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data4.4/15 Cues for Prompting Data Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>109 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/12 Marking Required and Optional Data Fields</span></text>
</content>
<name>1.4/12</name>
<script></script>
</card>
card_31896.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide cues in field delineation to indicate when a fixed or maximum length is specified for a data entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Prompting by delineation is more effective than simply telling the user how long an entry should be. In the example cited here, underscoring gives a direct visual cue as to the number of characters to be entered, and the user does not have to count them. Similar implicit cues should be provided when data entry is prompted by auditory displays. Tone codes can be used to indicate the type and length of data entries. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Enter ID: __ __ __ __ __ __ __ __ __ | </span><span class="style1">(Bad) </span><span class="style8">| Enter ID (9 characters): |</span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.4/1 Combined Entry of Related Data4.4/15 Cues for Prompting Data Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>108 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/11 Prompting Field Length</span></text>
</content>
<name>1.4/11</name>
<script></script>
</card>
card_31566.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Display special characters or other consistent means of highlighting to clearly delineate each data field. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Such implicit prompts help reduce data entry errors by the user. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">An underscore might be used for this purpose, perhaps broken to indicate the number of symbols required in an entry, as (Good) </span><span class="style8">| Enter account number: __ __ __ __ __ | </span><span class="style1">(Bad) </span><span class="style8">| Enter account number: |</span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.0/6 Defined Display Areas for Data Entry1.4/1 Combined Entry of Related Data2.2/2 Visually Distinctive Data Fields4.4/15 Cues for Prompting Data Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>107 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/10 Marking Field Boundaries</span></text>
</content>
<name>1.4/10</name>
<script></script>
</card>
card_31400.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Choose a standard symbol for input prompting and reserve that symbol only for that use. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Consistent use of a symbol for input prompting in data entry forms, in menus, in command entry lines, etc., will help to cue users that an input is required. A standard symbol used in addition to other formatting cues will help to alert a user to differences between labels and displayed data, between messages requiring input and messages for information only. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In the examples here, and also in many printed forms, a colon serves to prompt inputs, as (Good) </span><span class="style8">| TIME: ________ | </span><span class="style1">(Bad)</span><span class="style8">| TIME ________ | </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.5.2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data3.1.3/15 Standard Symbol for Prompting Entry4.4/10 Standard Symbol for Prompting Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>106 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/9 Standard Symbol for Prompting Entry</span></text>
</content>
<name>1.4/9</name>
<script></script>
</card>
card_31062.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that labels are sufficiently close to be associated with their proper data fields, but are separated from data fields by at least one space. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.9.5Engel Granda 1975 § 2.3.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data2.2/9 Labels Close to Data Fields</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>105 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/8 Labels Close to Data Fields</span></text>
</content>
<name>1.4/8</name>
<script></script>
</card>
card_30965.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Protect field labels from keyed entry, by making the cursor skip over them automatically when a user is spacing or tabbing. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When a user must change a displayed form, including changes to field labels, then that user must be able to override label protection. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.1/23 Display Format Protection1.4/1 Combined Entry of Related Data2.0/10 Protection of Displayed Data6.2/5 Protecting Display Formats6.3/2 Protection from Data Change</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>104 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/7 Protected Labels</span></text>
</content>
<name>1.4/7</name>
<script></script>
</card>
card_30692.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Make field labels consistent; always employ the same label to indicate the same kind of data entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A field labeled NAME should always require name entry, and not sometimes require something different like elevation (cited from an actual system). See sample displays in this section. </span><span class="style10"></span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>103 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/6 Consistent Labeling</span></text>
</content>
<name>1.4/6</name>
<script></script>
</card>
card_30367.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a field delimiter must be used for data entry, adopt a standard character to be employed consistently for that purpose. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Choose a special delimiter character that does not require shift keying. It will also be necessary to choose a character that does not occur as part of any data entry (except possibly for entry of running text where its occurrence would not be ambiguous). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A slash (/) may be a good choice. See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>101 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/4 Standard Delimiter Character</span></text>
</content>
<name>1.4/4</name>
<script></script>
</card>
card_29920.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Whenever possible, allow entry of multiple data items without keying special separator or delimiter characters, e.g., hyphens, dollar signs, etc. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This can be accomplished either by keying into predefined entry fields or by separating sequentially keyed items with blank spaces. In this context, tabbing from field to field is not considered to be keying a special delimiter character. When data items contain internal blanks, design the entry fields with a predefined structure so that users will not have to key any internal delimiters. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>100 of 944</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/3 Minimal Use of Delimiters</span></text>
</content>
<name>1.4/3</name>
<script></script>
</card>
card_29478.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When multiple data items are entered as a single transaction, as in form filling, allow the user to REVIEW, CANCEL, or BACKUP and change any item before taking a final ENTER action. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">See sample displays in section 1.4/1.</span></text>
<text>1.0/9 Explicit ENTER Action 1.4/1 Combined Entry of Related Data3.3/3 CANCEL Option3.3/4 BACKUP Option3.3/5 REVIEW Option3.5/2 Command Editing6.0/10 User Review and Editing of Entries6.3/8 Editing Data Before Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>99 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/2 Flexible Interrupt</span></text>
</content>
<name>1.4/2</name>
<script></script>
</card>
card_29349.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">∆ Statement</span><span class="style1">In a form-filling dialogue, when a user is entering logically related items, require just one explicit entry action at the end of the transaction sequence, rather than separate entry of each item. </span><span class="style10">∆∆ Comment</span><span class="style1">Depending on form design, this practice might involve entering the entire form, or entry by page or section of a longer form. Form design should indicate to users just where explicit entry is required. Single entry of grouped data will generally permit faster input than item-by-item entry, and should prove more accurate as well. This practice permits user review and possible data correction prior to entry, and also helps the user understand at what point grouped data are processed. It will also permit efficient cross validation of related data items by the computer. </span><span class="style10">∆∆ Example</span><span class="style1">These sample displays represent a possible form for entry and review ofvisa application data. In the good form, data entries are bolded tohelp distinguish them from labels and field delimiters. Fields areordered consistently in relation to a (supposed) paper application form,and formatted to facilitate both data entry and data review.The bad display is annotated to indicate violations of several of thedesign guidelines proposed here for data forms. The data entries in thebad display were invented to suggest what a user might have produced, ifconfused by inadequate labeling and the absence of field delimiters.Good Sample Data Form</span><span class="style8">|-----------------------------------------------------|| VISA APPLICATION || || NAME: Jones, Andrew David_______ VISA: 356 478 || LAST, FIRST MIDDLE || || BIRTH COUNTRY: UK DATE: 3/22/25 || MM DD YY || || NATIONALITY: UK PASSPORT: Z196284__ || || ADDRESS: 5 Fairview Lane_________________ || Loughborough, LE11 3RG__________ || England_________________________ || || OTHER TRAVELERS ON THIS VISA || BIRTH || NAME: COUNTRY: DATE: || Jones, Sandra Jean________ UK 10/11/28 || Jones, Cynthia Leigh______ FR 6/12/68< || __________________________ __ __/__/__ || __________________________ __ __/__/__ || LAST, FIRST MIDDLE MM DD YY || || * Press ENTER when done. ||-----------------------------------------------------|</span><span class="style1">Bad Sample Data Form</span><span class="style8">|-----------------------------------------------------|| Name Andrew D. Jones Visa Number 356478 || || Birthplace London Nationality English || || Passport Z196284 Birthdate Mar. 22, || || Address 1925 || 5 Fairview Lane, Loughborough, L || E11 3RG, England || || Other travelers on this visa || Traveler's Name Date of Birth - Place || Sandra J. Jones Oct. 11, - 1928 || Birmingham || Cynthia L. Jones June 12, - 1968 || Paris, France# || || || || || || || || Press ENTER when done ||-----------------------------------------------------|</span><span class="style1">This bad data form display violates in some degree several design guidelines in this section:1.4/3 Minimal use of delimiters1.4/6 Consistent labeling1.4/10 Marking field boundaries1.4/11 Prompting field length1.4/15 Explicit tabbing to data fields1.4/16 Distinctive label format1.4/18 Label punctuation as entry cue1.4/19 Informative labels1.4/20 Data format cueing in labels1.4/25 Form compatible with source documentsThis bad data form also violates various design guidelines pertaining todata display, as noted at the end of Section 2.2.</span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/9 Explicit ENTER Action1.4/3 Minimal use of delimiters1.4/6 Consistent labeling1.4/10 Marking field boundaries1.4/11 Prompting field length1.4/15 Explicit tabbing to data fields1.4/16 Distinctive label format1.4/18 Label punctuation as entry cue1.4/19 Informative labels1.4/20 Data format cueing in labels1.4/25 Form compatible with source documents6.3/6 Single Entry of Related Data6.3/18 Cross Validation of Related Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>98 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.4 Data Forms</span><span class="style21">1.4/1 Combined Entry of Related Data</span></text>
</content>
<name>1.4/1</name>
<script></script>
</card>
card_28986.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user signals completion of document editing, allow the user to confirm that changes should be made to the original document, or else to choose alternative options. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user will generally wish to replace the original document with its edited version. However, sometimes a user may decide that editing mistakes have been made, and wish to discard the new version while saving the original. Or a user might wish to save the new version as a separate document, while saving the original unchanged. Such decisions can be made best at the end of an editing session, when the user knows what has been accomplished, rather than before a session is begun. During text editing, the computer should always retain a copy of the original document until the user confirms that it should be changed. The original document should not be changed automatically as the user enters each editing change. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.0/18 User Confirmation of Destructive Actions6.3/19 User Confirmation of Destructive Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>97 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/34 User Confirmation of Editing Changes</span></text>
</content>
<name>1.3/34</name>
<script></script>
</card>
card_28883.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design text editing logic so that any user action is immediately reversible. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Reversible actions are particularly important in a text editing environment because text formatting often involves experimentation with features such as underscoring, bolding, and spacing. If users know that they can reverse whatever they do, they will feel more free to delete text and experiment with formatting features. An UNDO capability is currently available in some interface designs. In some applications, however, this capability is provided through the use of an UNDO key which can only reverse the most recent control action. For text editing, users must be able to reverse such formatting features as centering and bolding at any time. Therefore, if control actions are to be made reversible, an UNDO action should be able to reverse more than the most recent command, perhaps by requiring the user to specify which command to undo, and/or to place the cursor at the location of the format feature that is to be reversed. When text segments have been deleted, it should be possible to retrieve more than the most recent deletion. Some systems do this by storing all deletions in a special file. Deleted text which the user wishes to retrieve can then be moved from the deletion file to the file in which the user is presently working. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user centers a heading and then decides it would look better flush against the left margin, an UNDO action should reverse the centering and move the heading back to its original location. If a user underlines a paragraph of text and then decides it should be in all capital letters instead, an UNDO action should reverse the underlining. The user should not be required to delete the paragraph and retype it just to erase the underscoring. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">If a DELETE mode is used, highlight any text specified by a user for deletion and require the user to confirm the DELETE action before the computer will process it. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Requiring a user to confirm actions in DELETE mode is particularly important when the control entries for cursor positioning (e.g., WORD, SENTENCE, PARAGRAPH, PAGE) are also used to specify text for deletion, which is often the case. Users will associate the specification of text units primarily with cursor positioning, which is the most frequent action in text editing. In a DELETE mode, after specifying text units for deletion, a user may press a PARAGRAPH key intending to move to the next paragraph but accidentally delete the next paragraph. Confirmation of DELETE actions will tend to prevent such errors. An alternative approach to this problem is not to provide a continuing DELETE mode, but instead require double keying to accomplish deletions. In a DELETE mode, a user might press a DELETE key followed by unlimited repetitions of a WORD key (or keys specifying other units of text). With double keying, the user would have to press DELETE before each selection of a text unit to be deleted. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/6 Control Entry Based on Units of Text6.0/18 User Confirmation of Destructive Actions6.3/19 User Confirmation of Destructive Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>95 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/32 Confirming Actions in DELETE Mode</span></text>
</content>
<name>1.3/32</name>
<script></script>
</card>
card_28230.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When a user is inserting text into a document that has already been paginated, ensure that no text is lost if the user inserts more text than a page can hold. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">It is difficult for a user to keep track of page size, particularly if the size of the display screen is less than the full page specified for printed text, which is often the case. A user will often not know when more text has been inserted into a page than there is room for. The computer should accommodate text insertions with automatic repagination. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>94 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/31 Protecting Text During Page Overruns</span></text>
</content>
<name>1.3/31</name>
<script></script>
</card>
card_27970.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">During text entry/editing, provide an auditory signal whenever it is necessary to draw a user's attention to the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A touch typist entering text from written copy will often not be looking at the display screen, and therefore may not notice visual indicators of errors or mode changes unless they are accompanied by auditory signals. Note that in a group environment an auditory signal may distract other workers, and may embarrass the user whose error has been thus advertised. In such a work setting, consider allowing users to disable the auditory signal. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.6/39 Auditory Coding</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>93 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/30 Auditory Signals for Alerting Users</span></text>
</content>
<name>1.3/30</name>
<script></script>
</card>
card_27823.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Inform users concerning the status of requests for printouts. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a user is responsible for operating a local printer, the computer might display messages to alert the user of potential malfunctions, e.g., if its paper supply is exhausted, if the paper is not correctly loaded, etc. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">The computer should acknowledge print requests immediately, and might provide a subsequent message to indicate when a printout has been completed if the printer is remote (unobservable) from the user's work station. If there is a queue of documents waiting for printout, a user should be able to get an estimate as to when a particular document will be printed. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/14 Feedback for Control Entries4.2/5 Feedback for Print Requests</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>92 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/29 Information on Printing Status</span></text>
</content>
<name>1.3/29</name>
<script></script>
</card>
card_27598.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In printing text, allow users to select among available output formats (line spacing, margin size, etc.) and to specify the parts of a document to be printed; do not require that an entire document be printed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This is particularly important when long documents will be edited. A user should not be required to print an entire 50-page document just because of a change to one page. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Permit a user to print just those portions of a document that have been changed, perhaps specifying just the first page, or page 17, or the last five pages, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>91 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/28 Flexible Printing Options</span></text>
</content>
<name>1.3/28</name>
<script></script>
</card>
card_27257.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to display text exactly as it will be printed. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Accurate display is particularly necessary when the format of printed output is important, as when printing letters, tables, etc. Ideally, text displays should be able to represent all the features that are provided in printed output, including upper and lower case, underlining, bolding, subscripting, superscripting, special symbols, and different styles and sizes of type. When those features are important, the necessary display capability should be provided. For special formatting features that are not frequently used, it may be sufficient to use extra symbols to note text features that cannot be directly displayed. In that case, care should be taken that such annotation does not disturb the spacing of displayed text. This may require two display modes, one to show text spacing as it will be printed and the other to show annotations to the text. A corollary to this recommendation is that changes made to displayed text should appear as a user makes them. Some line-based editors show changes only after a document has been filed and later recalled for display, which does not represent good user interface design. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Van Dam 1982Gould 1981</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/1 Adequate Display Capacity</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>90 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/27 Text Displayed as Printed</span></text>
</content>
<name>1.3/27</name>
<script></script>
</card>
card_26950.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that annotations to displayed text are distinguishable from the text itself. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation refers to text annotations added by users, such as marginal notes on printed displays. Other annotation such as format control characters might be shown in a special display mode where text has been expanded to permit annotation between lines. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Continuous annotation might be displayed in the top and/or bottom lines of a page, separated from the text by blank lines; optional annotation might be displayed in window overlays. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/4 Control Entries Distinct from Text</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>89 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/26 Text Distinct from Annotation</span></text>
</content>
<name>1.3/26</name>
<script></script>
</card>
card_26822.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that whatever information a user needs for text entry/ editing is available for display, as an annotation to displayed text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Required annotation will vary with the application. Some annotation may be so commonly needed that it should be continuously displayed -- e.g., document name, page number, indication of control mode (if any), etc. Other annotation might be displayed only at user request -- such as document status (date last changed, last printed, etc.) which might be displayed in an optional window overlay, and format control characters which might be visible in an optional display mode. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish to see format control characters, such as tab and margin settings. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>88 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/25 Necessary Data Displayed</span></text>
</content>
<name>1.3/25</name>
<script></script>
</card>
card_26559.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to label and store frequently used text segments, and later to recall (copy into current text) stored segments identified by their assigned labels. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Much text processing involves repetitive elements specific to different applications, such as signature blocks, technical terms, long names, formulas or equations. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>87 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/24 Storing Frequently Used Text</span></text>
</content>
<name>1.3/24</name>
<script></script>
</card>
card_26328.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to select and move text segments from one place to another within a document. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user should not have to re-enter (i.e., rekey) text that is already available to the computer. One convenient method of allowing the user to both move and copy text is to provide a "cut and paste" facility in which the "cut" text remains in a storage buffer and can be "pasted" more than once. For copying, the user can cut text, paste it back into its original location, and paste it again at a new location. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/1 Data Entered Only Once</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>86 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/23 Moving Text</span></text>
</content>
<name>1.3/23</name>
<script></script>
</card>
card_26093.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When text formats cannot be predicted in advance, allow users to specify and store for future use the formats that might be needed for particular applications. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A special format might be adopted for generating a particular report at periodic intervals. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>85 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/22 Storing User-Defined Formats</span></text>
</content>
<name>1.3/22</name>
<script></script>
</card>
card_25711.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When text formats must follow predefined standards, provide the standard format automatically; do not rely on users to remember and specify proper formats. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Standard formats might be required for letters, memos, or other transmitted messages. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>5.1/6 Automatic Text Formatting</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>84 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/21 Establishing Predefined Formats</span></text>
</content>
<name>1.3/21</name>
<script></script>
</card>
card_25590.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide easy means for users to specify required format control features during text entry/editing, e.g., to specify margin and tab settings. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Required format features will vary depending on the application. For instance, font size may be quite important when composing text for typesetting but unnecessary when editing computer programs. The intent of this guideline is that all required format features should be easy to control, and should take priority in interface design. Any format features which are provided but are optional for the user's task should not be made easy to use at the expense of required format features. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">One convenient method of margin and tab control is to allow users to mark settings on a displayed "ruler" that extends the width of a page and is continuously displayed at the top of the screen. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>83 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/20 Format Control by User</span></text>
</content>
<name>1.3/20</name>
<script></script>
</card>
card_25250.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In the entry/editing of text, ensure that automatic pagination and line breaks by the computer keep words intact, and introduce hyphenation only where specified by users. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Where compound words have been hyphenated by a user, the computer might break the compound after a hyphen, for pagination or line breaks, unless otherwise specified by the user. Compound words formed with slashes (e.g., "entry/ editing") might be treated in a similar manner. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/9 Minimal Hyphenation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>82 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/19 Hyphenation by Users</span></text>
</content>
<name>1.3/19</name>
<script></script>
</card>
card_24972.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Unless otherwise specified by the user, ensure that entered text is left-justified to maintain constant spacing between words, leaving right margins ragged if that is the result. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.1/8 Consistent Word Spacing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>81 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/18 Consistent Word Spacing</span></text>
</content>
<name>1.3/18</name>
<script></script>
</card>
card_24671.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For entry/editing of unformatted text, provide an automatic line break ("carriage return") when text reaches the right margin, with provision for user override. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For specially formatted text, such as computer program listings, users may need to control line structure themselves and hence need to override any automatic line break. Even when entering unformatted text, a user will sometimes wish to specify a new line at some particular point, if only for esthetic reasons. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>80 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/17 Automatic Line Break</span></text>
</content>
<name>1.3/17</name>
<script></script>
</card>
card_24514.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When automatic pagination is provided, allow users to specify the number of lines in a paragraph that will be allowed to stand alone at the top or bottom of a page (i.e., the size of "widows" and "orphans"), and to specify any text that should not be divided between two pages, such as inserted lists or tables. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>79 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/16 Controlling Integrity of Text Units</span></text>
</content>
<name>1.3/16</name>
<script></script>
</card>
card_24172.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When automatic pagination is provided, allow users to override that pagination in order to specify page numbers at any point in a document. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When producing a large document, a user may wish to split it into several separate text files for convenience in editing, and hence need to control the page numbering of those component sections. In general, a user will want flexibility in assembling different computer files to create a composite document. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user might wish to number the first page of a document "23", or perhaps skip a page number in the middle of a document. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>78 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/15 User Control of Pagination</span></text>
</content>
<name>1.3/15</name>
<script></script>
</card>
card_23857.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide automatic pagination for text entry/editing, allowing users to specify the page size. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For short documents, automatic pagination may not be needed. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>77 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/14 Automatic Pagination Aids</span></text>
</content>
<name>1.3/14</name>
<script></script>
</card>
card_23763.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a global search and replace capability is provided, ensure that each time a string is replaced the case of the new string matches the case of the old string, unless otherwise specified by the user. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">On occasion, however, a user might wish to replace an erroneous lower-case word ("Mitre") with a correctly capitalized version ("MITRE"). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a word is replacing the first word in a sentence, the first letter of the new word should be capitalized; if it is replacing a word that is entirely in lower case, then the new word should also be in lower case. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>76 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/13 Case in Global Search and Replace</span></text>
</content>
<name>1.3/13</name>
<script></script>
</card>
card_23430.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When systematic editing changes will be made throughout a long document, consider providing a "global search and replace" capability in which the computer will replace all occurrences of one text string with another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Global search and replace could be designed in two different ways. One user might want the computer to make all changes automatically. Another user might want to review and confirm each change. Ideally, both options should be available. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>75 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/12 Global Search and Replace</span></text>
</content>
<name>1.3/12</name>
<script></script>
</card>
card_23276.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When case is important, allow users to specify case as a selectable option in string search. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Users may also wish to specify features such as bolding, underlining, and quotes when searching text. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">When searching a document in which all the headings are capitalized, a user might wish to find a string only when it appears in a heading. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>74 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/11 Specifying Case in Search</span></text>
</content>
<name>1.3/11</name>
<script></script>
</card>
card_22808.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Unless otherwise specified by a user, treat upper and lower case letters as equivalent in searching text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In searching for words, users will generally be indifferent to any distinction between upper and lower case. The computer should not compel a distinction that users do not care about and may find difficult to make. In situations when case actually is important, allow users to specify case as a selectable option in string search. It may also be useful for the computer to ignore such other features as bolding, underlining, parentheses and quotes when searching text. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">"STRING", "String", and "string" should all be recognized/accepted by the computer when searching for that word. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/27 Upper and Lower Case Equivalent3.0/12 Upper and Lower Case Equivalent</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>73 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/10 Upper and Lower Case Equivalent in Search</span></text>
</content>
<name>1.3/10</name>
<script></script>
</card>
card_22738.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify a string of text and request the computer to advance (or back up) the cursor automatically to the next (or last previous) occurrence of that string. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Novice users may prefer to move through a displayed document by units of text, such as by word or paragraph. More experienced users, however, may sometimes wish to specify cursor placement directly. An automatic string search capability will generally speed cursor placement in comparison with incremental positioning, particularly when moving over large portions of a document. Expert users may also wish to incorporate special characters in string search, including format control characters such as those for tabbing, bolding, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Elkerton etal 1982</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>72 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/9 String Search</span></text>
</content>
<name>1.3/9</name>
<script></script>
</card>
card_22487.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to move the cursor by specific units of text, as well as one character at a time. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The time necessary to position a cursor is directly related to the number of control actions required. Incremental cursor movement by character will therefore be inefficient when moving the cursor over large units of text. Cursor positioning will be easier if appropriate function keys can be provided. A SENTENCE key that allows a user to move directly to the next displayed sentence will be more convenient than some double-keying logic such as CONTROL-S. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/7 Responsive Cursor Control</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>71 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/8 Cursor Movement by Units of Text</span></text>
</content>
<name>1.3/8</name>
<script></script>
</card>
card_22250.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When text has been specified to become the subject of control entries, highlight that segment of text in some way to indicate its boundaries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Text may be specified for various purposes -- for underlining or bolding, moving, copying, or deleting. Highlighting provides the user with direct feedback on the extent and content of specified text, reducing the likelihood of specification errors. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.2/10 Indicating Item Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>70 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/7 Highlighting Specified Text</span></text>
</content>
<name>1.3/7</name>
<script></script>
</card>
card_21990.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify units of text as modifiers for control entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Control entries, whether accomplished by function key, menu selection, or command entry, will be easier and more powerful when a user can specify text in natural units, rather than having to repeat an entry for each text character. When units of text are modifiers for all control entries, the syntax for those control entries will be easier to learn. Whether a control action is to MOVE or to DELETE, the modifiers to specify text are the same. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Consider two alternative control sequences to delete a four-character word: (Good) </span><span class="style8">DELETE WORD</span><span class="style1"> (Bad) </span><span class="style8">DELETE DELETE DELETE DELETE</span><span class="style1"> </span></text>
<text>3.0/6 Consistent User Actions4.0/1 Standard Procedures</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>69 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/6 Control Entry Based on Units of Text</span></text>
</content>
<name>1.3/6</name>
<script></script>
</card>
card_21721.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to specify segments of text in whatever units are natural for entry/editing. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For unformatted ("free") text, natural units will be characters, words, phrases, sentences, paragraphs, and pages; for specially formatted text, such as computer program listings, allow specification of other logical units, including lines, subsections, sections, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>68 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/5 Natural Units of Text</span></text>
</content>
<name>1.3/5</name>
<script></script>
</card>
card_21265.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If control entries are made by keying onto the display, such as by keyed menu selections or commands, ensure that they will be distinguishable from displayed text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The intent here is to help ensure that a user will not inadvertently enter controls as text, or vice versa. If a command entry is keyed into the body of a text display, perhaps at the end of the last sentence, then a user cannot be certain whether the computer will interpret the command as a text entry or as a control entry. In applications where the screen cannot display all possible format features (e.g., special fonts), format codes representing those features are usually displayed within the text. It is not practical in such cases to display format codes in a separate window, since a displayed code must mark the text that will be affected by the code. These codes should therefore be highlighted in some way to distinguish them from text. One way of avoiding the problem altogether is to use function keys rather than command entry to control text editing. To provide a general range of text editing functions, however, many keys will be needed. A practical design approach might be to adopt double-keying logic for all keys on a standard (QWERTY) keyboard, where control-F means FILE a document, control-G means GET a document, etc., and providing appropriate extra labels for those keys. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Keyed control entries might be made only in a reserved window in the display. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/26 Text Distinct from Annotation</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>67 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/4 Control Entries Distinct from Text</span></text>
</content>
<name>1.3/4</name>
<script></script>
</card>
card_21076.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For text editing, allow users to move the cursor freely over a displayed page of text to specify items for change, and to make changes directly to the text. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Free cursor movement and changes made directly to the text are characteristics usually associated with so-called screen-based editors and not associated with line- or command-based editors. Screen-based editors are preferred by users and are potentially more efficient. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to do at least some simple editing during text entry without having to invoke a separate edit mode. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The intent of this guideline is not to endorse modeless over moded text editors. In fact, when experienced users perform editing tasks, a moded editor may offer some advantages. However if a moded editor is provided, users should be able to do some simple editing such as correcting typographical errors and making simple word changes without having to invoke that editor. When users will compose text on-line, consider providing a modeless editor rather than a moded editor. Modeless editors offer some advantages for text composition, when users will frequently alternate between text entry and editing. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">While entering text, users will need at least some capability for text selection (by cursor movement) and deletion. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Poller Garter 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>2.0/9 User Changes to Displayed Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>65 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/2 Editing Capabilities During Text Entry</span></text>
</content>
<name>1.3/2</name>
<script></script>
</card>
card_20641.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that display capacity, i.e., number of lines and line length, is adequate to support efficient performance of text entry/editing tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A single line of displayed text should not be used for text editing. During text editing, a user will need to see some displayed context in order to locate and change various text entries. Displaying only a small portion of text will make a user spend more time moving forward and back in a displayed document to see other parts, will increase load on the user's memory, and will cause users to make more errors. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For text editing where the page format of subsequent printed output is critical, the user's terminal should be able to display full pages of text in final output form, which might require a display capacity of 50-60 lines or more. For general text editing where a user might need to make large changes in text, i.e., sometimes moving paragraphs and sections, a display capacity of at least 20 lines should be provided. Where text editing will be limited to local changes, i.e., correcting typos and minor rewording, as few as seven lines of text might be displayed. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Elkerton etal 1982Neal Darnell 1984</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/27 Text Displayed as Printed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>64 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.3 Text</span><span class="style21">1.3/1 Adequate Display Capacity</span></text>
</content>
<name>1.3/1</name>
<script></script>
</card>
card_20447.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When designation of direction is based on already quantified data, allow keyed entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A heading entry might be made from a verbal report in which the direction has already been expressed numerically. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>63 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.2 Direction Designation</span><span class="style21">1.2/2 Keyed Entry of Quantified Direction</span></text>
</content>
<name>1.2/2</name>
<script></script>
</card>
card_20199.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When direction designation is based on graphic representation, provide some analog means of entry, such as vector rotation on the display and/or a suitably designed rotary switch. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For matching the directional elements in a graphic display, an entry device providing a visual analog will prove both faster and more accurate. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When approximate direction designation will suffice, for just eight cardinal points, keyed entry can be used. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A rotary switch might be used to indicate heading estimations for displayed radar trails. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Smith 1962a</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>62 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.2 Direction Designation</span><span class="style21">1.2/1 Analog Entry of Estimated Direction</span></text>
</content>
<name>1.2/1</name>
<script></script>
</card>
card_19958.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that an ENTER action for multiple data items results in entry of all items, regardless of where the cursor is placed on the display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">A user may choose to move the cursor back to correct earlier data items, and may not move the cursor forward again. The computer should ignore cursor placement in such cases. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.3/7 Data Entry Independent of Cursor Placement</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>61 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/24 Data Entry Independent of Cursor Placement</span></text>
</content>
<name>1.1/24</name>
<script></script>
</card>
card_19625.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When there are areas of a display in which data entries cannot be made (blank spaces, protected field labels, etc.), make those areas insensitive to pointing actions, i.e., prevent the cursor from entering those areas. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic format protection will generally make cursor positioning easier for a user, since the cursor will not have to be stepped through blank areas, and much routine cursor control can be accomplished with only casual reference to the display. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When a user may have to modify display formats, then this automatic format protection can be provided as a general default option subject to user override. </span></text>
<text>1.4/7 Protected Labels2.0/10 Protection of Displayed Data6.2/5 Protecting Display Formats</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>60 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/23 Display Format Protection</span></text>
</content>
<name>1.1/23</name>
<script></script>
</card>
card_19263.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a cursor must be positioned sequentially in predefined areas, such as displayed data entry fields, ensure that this can be accomplished by simple user action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic cursor advance is generally not desirable. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Programmable tab keys are customarily used for this purpose. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.4.3.6</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/26 Minimal Cursor Positioning</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>59 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/22 Easy Cursor Movement to Data Fields</span></text>
</content>
<name>1.1/22</name>
<script></script>
</card>
card_19017.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">On the initial appearance of a data entry display, ensure that the cursor will appear automatically at some consistent and useful location. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In a form-filling display, the cursor should be placed in the first entry field. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When there is a predefined HOME position for the cursor, which is usually the case, define that position consistently on all displays of a given type. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The HOME position of the cursor should also be consistent in the different "windows" or sections of a partitioned display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">HOME might be in the upper left corner of a text display, or at the first field in a form-filling display, or at the center of a graphic display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.1.8.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>4.4/16 Consistent Cursor Positioning</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>57 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/20 Consistent HOME Position</span></text>
</content>
<name>1.1/20</name>
<script></script>
</card>
card_18442.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If multiple cursors are controlled by different devices, ensure that their separate controls are compatible in operation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Assume that one cursor is moved upward on a display by forward motion of a joystick. Then a second cursor should also be moved upward by forward motion -- perhaps by forward motion of a second joystick or by forward motion of a thumbwheel or other device. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Morrill Davies 1961</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/16 Compatibility with User Expectations</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>56 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/19 Compatible Control of Multiple Cursors</span></text>
</content>
<name>1.1/19</name>
<script></script>
</card>
card_18336.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If multiple cursors are controlled by a single device, provide a clear signal to the user to indicate which cursor is currently under control. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>55 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/18 Distinctive Control of Multiple Cursors</span></text>
</content>
<name>1.1/18</name>
<script></script>
</card>
card_18123.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If multiple cursors are used, make them visually distinctive from one another. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.1/1 Distinctive Cursor</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>54 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/17 Distinctive Multiple Cursors</span></text>
</content>
<name>1.1/17</name>
<script></script>
</card>
card_17835.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Employ multiple cursors on a single display only when they are justified by careful task analysis. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Multiple cursors may confuse a user, and so require special consideration if advocated in USI design. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Multiple cursors might be useful to mark a user's place when manipulating data in multiple display windows. In graphic interaction, one cursor might be used for line drawing and a different cursor for alphanumeric data entry (labels, etc.). </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>53 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/16 Minimal Use of Multiple Cursors</span></text>
</content>
<name>1.1/16</name>
<script></script>
</card>
card_17502.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that control actions for cursor positioning are compatible with movements of the displayed cursor, in terms of control function and labeling. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">For cursor control by key action, a key labeled with a left-pointing arrow should move the cursor leftward on the display; for cursor control by joystick, leftward movement of the control (or leftward pressure) should result in leftward movement of the cursor; etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/16 Compatibility with User Expectations</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>52 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/15 Compatible Control of Cursor Movement</span></text>
</content>
<name>1.1/15</name>
<script></script>
</card>
card_17337.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When position designation is required in a task emphasizing keyed data entry, provide cursor control by some device integral to the keyboard (function keys, joystick, "cat", etc.). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Separately manipulated devices (lightpen, "mouse", etc.) will tend to slow the user. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Foley Wallace 1974</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/5 Single Method for Entering Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>51 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/14 Cursor Control at Keyboard</span></text>
</content>
<name>1.1/14</name>
<script></script>
</card>
card_16970.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">In selection of displayed alternatives, design the acceptable area for pointing (i.e., cursor placement) to be as large as consistently possible, including at least the area of the displayed label plus a half-character distance around the label. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The larger the effective target area, the easier the pointing action will be, and the less risk of error in selecting the wrong label by mistake. Some researchers have recommended a target separation on the display of no less than 6 mm. </span></text>
<text>3.1.3/5 Large Pointing Area for Option Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>50 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/13 Large Pointing Area for Option Selection</span></text>
</content>
<name>1.1/13</name>
<script></script>
</card>
card_16689.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When position designation is the sole or primary means of data entry, as in selection among displayed alternatives, provide cursor placement by direct pointing (e.g., with a touch display or lightpen) rather than incremental stepping or slewing controls (e.g., keys, joystick, etc.). </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/12 Direct Pointing</span></text>
</content>
<name>1.1/12</name>
<script></script>
</card>
card_16483.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For continuous position designation, such as needed for line drawing, provide a continuously operable control (e.g., joystick) rather than requiring a user to take incremental, discrete key actions. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6.2 Graphics Drawing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>48 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/11 Continuous Cursor Positioning</span></text>
</content>
<name>1.1/11</name>
<script></script>
</card>
card_16313.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If proportional spacing is used for displayed text, provide computer logic to make necessary adjustments automatically when the cursor is being positioned for data entry or data change. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Without automatic computer aids, a user probably will not handle proportional spacing accurately. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Manual override may help a user in special cases where automatic spacing is not wanted. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Automatic proportional spacing is useful for cursor control when editing text composed for typesetting. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>47 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/10 Proportional Spacing</span></text>
</content>
<name>1.1/10</name>
<script></script>
</card>
card_15955.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When character size is variable, design the incremental cursor positioning to vary correspondingly, with a step size matching the size of currently selected characters. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>46 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/9 Variable Step Size</span></text>
</content>
<name>1.1/9</name>
<script></script>
</card>
card_15859.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When cursor positioning is incremental by discrete steps, design the step size of cursor movement to be consistent horizontally (i.e., in both right and left directions), and consistent vertically (in both up and down directions). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Horizontal and vertical step sizes need not be the same, and in general will not be. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>45 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/8 Consistent Incremental Positioning</span></text>
</content>
<name>1.1/8</name>
<script></script>
</card>
card_15585.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For arbitrary position designation, moving a cursor from one position to another, design the cursor control to permit both fast movement and accurate placement. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Ideally, when the user moves a pointing device the displayed cursor should appear to move instantly. Rough positioning should take no more than 0.5 seconds for full screen traversal. Fine positioning may require incremental stepping of the cursor, or a control device incorporating a large control/display ratio for small displacements, or a selectable vernier mode of control use. For any given cursor control action, the rate of cursor movement should be constant, i.e., should not change with time. Slow visual feedback of cursor movement can be particularly irritating when a user is repeatedly pressing a cursor control key, or perhaps holding the key down. In that case, slow feedback will cause the user to misjudge location and move the cursor too far. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>44 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/7 Responsive Cursor Control</span></text>
</content>
<name>1.1/7</name>
<script></script>
</card>
card_15156.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the displayed cursor will be stable, i.e., that it will remain where it is placed until moved by the user (or by the computer) to another position. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Some special applications, such as aided tracking, may benefit from computer-controlled cursor movement. The intent of the recommendation here is to avoid unwanted "drift". </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 6.1</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>43 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/6 Stable Cursor</span></text>
</content>
<name>1.1/6</name>
<script></script>
</card>
card_14930.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer will acknowledge entry of a designated position within 0.2 seconds. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In some applications it may be desirable to provide an explicit message indicating that a selection has been made. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Almost any consistently provided display change will suffice to acknowledge pointing actions, such as brightening or flashing a selected character. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 2MIL-STD-1472C 1983 § 5.15.8</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/3 Feedback During Data Entry4.2/2 Fast Response4.2/10 Indicating Item Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>42 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/5 Fast Acknowledgement of Entry</span></text>
</content>
<name>1.1/5</name>
<script></script>
</card>
card_14769.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require users to take a separate, explicit action, distinct from cursor positioning, for the actual entry (enabling, activation) of a designated position. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For line drawing or tracking tasks the need for rapid, continuous entry may override the need to reduce entry errors. </span></text>
<text>1.6/4 Confirming Cursor Position3.1.3/6 Dual Activation for Pointing</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>41 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/4 Explicit Activation</span></text>
</content>
<name>1.1/4</name>
<script></script>
</card>
card_14436.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When fine accuracy of positioning is required, as in some forms of graphic interaction, design the displayed cursor to include a point designation feature. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Precise pointing will also require a cursor control device capable of precise manipulation. Touch displays, for example, will not permit precise pointing. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A cross may suffice (like cross-hairs in a telescope), or perhaps a notched or V-shaped symbol (like a gun sight). </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/3 Precise Pointing</span></text>
</content>
<name>1.1/3</name>
<script></script>
</card>
card_14184.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the cursor so that it does not obscure any other character displayed in the position designated by the cursor. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A block cursor might employ brightness inversion ("reverse video") to show any other character that it may be marking. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>39 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/2 Nonobscuring Cursor</span></text>
</content>
<name>1.1/2</name>
<script></script>
</card>
card_14043.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For position designation on an electronic display, provide a movable cursor with distinctive visual features (shape, blink, etc.). </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When choosing a cursor shape, consider the general content of the display. For instance, an underscore cursor would be difficult to see on a display of underscored text, or on a graphical display containing many other lines. If the cursor is changed to denote different functions (e.g., to signal deletion rather than entry), then each different cursor should be distinguishable from the others. If multiple cursors are used on the same display (e.g., one for alphanumeric entry and one for line drawing), then each cursor should be distinguishable from the others. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">When position designation involves only selection among displayed alternatives, highlighting selected items might be used instead of a separately displayed cursor. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.1 Position Designation</span><span class="style21">1.1/1 Distinctive Cursor</span></text>
</content>
<name>1.1/1</name>
<script></script>
</card>
card_13812.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide PAUSE and CONTINUE options for speech input, so that a user can stop speaking without having to log off the system. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A user may wish to stop speaking data for a time in order to answer a telephone, or to speak with a fellow worker. Users should not have to log off the system every time they wish to say something that is not intended as an entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3/8 PAUSE and CONTINUE Options3.3/9 Indicating PAUSE Status</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>37 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/37 PAUSE and CONTINUE Options for Speech Input</span></text>
</content>
<name>1.0/37</name>
<script></script>
</card>
card_13473.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When speech input is the only form of data entry available, allow alternatives for critical entries, so that if the system cannot recognize an entry after repeated attempts another entry can be substituted. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Because speech recognition systems are affected by normal variations in a user's voice, and by changes in the acoustic environment, a spoken entry that was accepted yesterday might not be accepted today. Thus for important entries a user should be able to use an alternative word. Spelling a word letter-by-letter is not an acceptable alternative, since speech recognition systems may have trouble correctly identifying similar sounding letters. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">"Exit" might be defined as an acceptable substitute for "Finished". </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>36 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/36 Alternative Entries for Speech Input</span></text>
</content>
<name>1.0/36</name>
<script></script>
</card>
card_13058.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide feedback and simple error correction procedures for speech input, so that when a spoken entry has not been correctly recognized by the computer, the user can cancel that entry and speak again. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Simple error correction is particularly important with spoken data entry, since speech recognition systems are prone to error except under carefully controlled conditions. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>35 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/35 Easy Error Correction for Speech Input</span></text>
</content>
<name>1.0/35</name>
<script></script>
</card>
card_13009.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the spoken entries needed for any transaction are phonetically distinct from one another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Words which are easily distinguished by one speech recognition system may be confused by another. Thus system testing should be performed in order to determine what sounds a particular system tends to confuse, and what sounds it can distinguish reliably. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>34 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/34 Phonetically Distinct Vocabulary for Speech Input</span></text>
</content>
<name>1.0/34</name>
<script></script>
</card>
card_12598.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Structure the vocabulary used for spoken data entry so that only a few options are needed for any transaction. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">To increase the likelihood that a user's valid entries are correctly identified by the system, the user's vocabulary should be predictable. This does not necessarily mean that the vocabulary must be small, though recognition systems that can only accommodate small vocabularies are more prevalent and less expensive. A vocabulary is predictable when a user's choice of inputs at any given time is small, so that the system will be more likely to make a correct match in interpreting an entry. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>33 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/33 Limited Vocabulary for Speech Input</span></text>
</content>
<name>1.0/33</name>
<script></script>
</card>
card_12291.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Consider spoken data input only when data entry cannot be accomplished through more reliable methods such as keyed entry or pointing. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Current speech recognition devices are not well developed and tend to be error prone. Thus there should be some good reason for choosing speech input over more conventional data entry methods. Speech input might be appropriate if a user cannot use his/her hands, perhaps because of a physical handicap or because the user's hands are needed to accomplish other tasks. Speech input may also be appropriate if a user does not have access to a suitable keyboard, as might be the case if data were being entered by telephone. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Postal workers whose hands are occupied sorting packages might speak ZIP codes into a speech recognition device rather than keying entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>32 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/32 Speech Input</span></text>
</content>
<name>1.0/32</name>
<script></script>
</card>
card_12237.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user must enter hierarchic data, where some items will be subordinate to others, provide computer aids to help the user specify relations in the hierarchic structure. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For simple data structures, question-and-answer dialogues or form filling may suffice to maintain necessary data relations. For more complex data structures, such as those involved in graphic data entry, special techniques may be needed to help users specify the relations among data entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.6/18 Aids for Entering Hierarchic Data1.8/12 Aids for Entering Hierarchic Data</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>31 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/31 Aids for Entering Hierarchic Data</span></text>
</content>
<name>1.0/31</name>
<script></script>
</card>
card_11892.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Treat single and multiple blank characters as equivalent in data entry; do not require users to count blanks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">People cannot be relied upon to pay careful attention to such details. The computer should handle them automatically, e.g., ensuring that two spaces follow every period in text entry (if that is the desired convention), and spacing other data items in accord with whatever format has been defined. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.1.5/17 Ignoring Blanks in Command Entry</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>30 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/30 Single and Multiple Blanks Equivalent</span></text>
</content>
<name>1.0/30</name>
<script></script>
</card>
card_11553.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For general numeric data, allow optional entry or omission of leading zeros as equivalent alternatives. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Special cases may represent exceptions to this rule, such as entry of serial numbers or other numeric identifiers. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">If a user enters "56" in a field that is four characters long, the system should recognize that entry rather than requiring an entry of "0056". </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.2.3Engel Granda 1975 § 6.3.11</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>29 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/29 Leading Zeros Optional</span></text>
</content>
<name>1.0/29</name>
<script></script>
</card>
card_11294.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow optional entry or omission of a decimal point at the end of an integer as equivalent alternatives. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a decimal point is required for data processing, the computer should probably be programmed to append one as needed. Most users will forget to do it. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">An entry of "56." should be processed as equivalent to an entry of "56", and vice versa. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Keister Gallaway 1983</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>28 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/28 Decimal Point Optional</span></text>
</content>
<name>1.0/28</name>
<script></script>
</card>
card_11258.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For coded data entry, treat upper and lower case letters as equivalent. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For data codes, users find it difficult to remember whether upper or lower case letters are required, and so the software design should not try to make such a distinction. For text entry, however, conventional use of capitalized letters should be maintained. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.3/10 Upper and Lower Case Equivalent in Search3.0/12 Upper and Lower Case Equivalent</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>27 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/27 Upper and Lower Case Equivalent</span></text>
</content>
<name>1.0/27</name>
<script></script>
</card>
card_10976.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design data entry transactions to minimize the need for shift keying. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Shift keying can be considered a form of double keying, which imposes a demand for extra user attention. Keyboard designers should put frequently used characters where they can be easily keyed. Conversely, software designers should avoid frequent use of characters requiring shift keying. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 6.3.12</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>26 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/26 Minimal Shift Keying</span></text>
</content>
<name>1.0/26</name>
<script></script>
</card>
card_10662.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to enter each character of a data item with a single stroke of an appropriately labeled key. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Devices that involve complex keying methods for alphabetic entry (e.g., pressing more than one key, simultaneously or successively) require special user training and risk frequent data entry errors. When hardware limitations such as those of a telephone keypad seem to require double keying of alphabetic entries, try to limit data codes so that only single-keyed (numeric) entries are required. Alternatively, consider providing software to interrogate the user to resolve any ambiguities resulting from single-keyed alphabetic entries. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, when a keyboard is intended primarily for numeric input, with several letters grouped on each key such as a telephone keypad, do not require a user to make alphabetic entries by double keying. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/25 Character Entry via Single Keystroke</span></text>
</content>
<name>1.0/25</name>
<script></script>
</card>
card_10436.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide prompting for the required formats and acceptable values for data entries. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Prompting is particularly needed for coded data entries. Menu selection may be appropriate for that purpose, because menu selection does not require the user to remember codes but merely to choose among displayed alternatives. Other methods of prompting include labeling data fields, such as</span><span class="style8"> | Vehicle type (c/t/b): __ |</span><span class="style1"> and/or providing optional guidance displays. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Prompting may not be needed by skilled users and indeed may hinder rather than help their performance in situations where display output is slow (as with Teletype displays); for such users prompting might be provided as an optional aid. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">(Good) </span><span class="style8">| Vehicle type: __ | | c = Car | | t = Truck | | b = Bus | </span><span class="style1">(Bad) </span><span class="style8">| Vehicle type: __ |</span><span class="style1"> </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Gade etal 1981Seibel 1972</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/5 Data Field Labels4.4/7 Prompting Entries3.1.3 Dialogue Type Menu Selection</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>24 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/24 Prompting Data Entry</span></text>
</content>
<name>1.0/24</name>
<script></script>
</card>
card_9996.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When the computer cannot recognize an abbreviated data entry, question the user as necessary to resolve any ambiguity. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">This may occur when a user enters a misremembered abbreviation. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>23 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/23 Clarifying Unrecognized Abbreviations</span></text>
</content>
<name>1.0/23</name>
<script></script>
</card>
card_9812.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Make abbreviations the same length, the shortest possible that will ensure unique abbreviations. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Desirable length will depend upon the vocabulary size of words to be abbreviated. For a vocabulary of 75 words, 4-letter abbreviations might suffice. For smaller vocabularies, still shorter abbreviations might be used. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Moses Ehrenreich 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>22 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/22 Fixed Abbreviation Length</span></text>
</content>
<name>1.0/22</name>
<script></script>
</card>
card_9717.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When an abbreviation must deviate from the consistent rule, minimize the extent of deviation. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">In abbreviation by truncation, letters in the truncated form should be changed one at a time until a unique abbreviation is achieved. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Moses Ehrenreich 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>21 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/21 Minimal Deviation from Abbreviation Rule</span></text>
</content>
<name>1.0/21</name>
<script></script>
</card>
card_9315.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Use special abbreviations (i.e., those not formed by consistent rule) only when they are required for clarity. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Special abbreviations will sometimes be needed to distinguish between words whose abbreviations by rule are identical, or when abbreviation by rule forms another word, or when the special abbreviation is already familiar to system users. If more than 10 percent of abbreviations are special cases, consider changing the abbreviation rule. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Moses Ehrenreich 1981</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>20 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/20 Minimal Exceptions to Abbreviation Rule</span></text>
</content>
<name>1.0/20</name>
<script></script>
</card>
card_9111.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When defining abbreviations, follow some simple abbreviation rule and ensure that users understand that rule. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When encoding abbreviations for data entry the user must know what the rule is. Truncation provides novice users with a straightforward and highly successful method for generating abbreviations, and is a rule that can be easily explained. Moreover, truncation works at least as well, and often better than, more complicated rules, such as word contraction with omission of vowels. Designers of military systems may wish to consult the relevant standard for abbreviations, MIL-STD-12D. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Simple truncation is probably the best rule when that can be done without ambiguity. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When defining abbreviations or other codes to shorten data entry, choose them to be distinctive in order to avoid confusing similarity with one another. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">BOS vs. LAS is good; but LAX vs. LAS risks confusion. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">Allow optional abbreviation of lengthy data items to minimize data entry keying by expert users, when that can be done without ambiguity. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Novice and/or occasional users may prefer to make full-form entries, while experienced users will learn and benefit from appropriate abbreviations. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">When a long data item must be entered, it should be partitioned into shorter symbol groups for both entry and display. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A 10-digit telephone number can be entered as three groups, NNN-NNN-NNNN. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/16 Partitioning Long Data Items</span></text>
</content>
<name>1.0/16</name>
<script></script>
</card>
card_8079.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For coded data, numbers, etc., keep data entries short, so that the length of an individual item will not exceed 5-7 characters. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For coded data, lengthy items may exceed a user's memory span, inducing errors in both data entry and data review. The nine-digit ZIP codes proposed by the US Postal Service will prove difficult to remember accurately. Proper names, meaningful words, and other textual material are not coded data. Such items can be remembered more easily, and the length restriction recommended here need not apply. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Coded data may include such items as badge numbers, payroll numbers, mail stops, equipment and part numbers, etc. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 1.5.2Engel Granda 1975 § 6.3.3</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>15 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/15 Keeping Data Items Short</span></text>
</content>
<name>1.0/15</name>
<script></script>
</card>
card_7736.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">If a user requests change (or deletion) of a data item that is not currently being displayed, offer the user the option of displaying the old value before confirming the change. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Displayed feedback will help prevent inadvertent data change, and is particularly useful in protecting delete actions. Like other recommendations intended to reduce error, it assumes that accuracy of data entry is worth extra effort by the user. For some tasks, that may not be true. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">Expert users may sometimes wish to implement data changes without displayed feedback, as in "global replace" transactions, accepting the attendant risk. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>6.3/16 Displaying Data to be Changed</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>14 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/14 Feedback when Changing Data</span></text>
</content>
<name>1.0/14</name>
<script></script>
</card>
card_7656.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">For a repetitive data entry task that is accomplished as a continuing series of transactions, indicate successful entry by regenerating the data entry display, automatically removing the just-entered data in preparation for the next entry. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Automatic erasure of entered data represents an exception to the general principle of control by explicit user action. The interface designer may adopt this approach, in the interests of efficiency, for data entry transactions that task analysis indicates will be performed repetitively. In addition to erasure of entered data, a message confirming successful data entry might be displayed. Such a message may reassure uncertain users, especially in system applications where computer performance is unreliable. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 4.2.10</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/3 Feedback During Data Entry3.0/14 Feedback for Control Entries4.2/1 Consistent Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>13 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/13 Feedback for Repetitive Data Entries</span></text>
</content>
<name>1.0/13</name>
<script></script>
</card>
card_7217.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer will acknowledge completion of a data entry transaction with a confirmation message, if data entry was successful, or else with an error message. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Successful data entry should not be signaled merely by automatic erasure of entered data from the display, except possibly in the case of repetitive data entries. For single data entry transactions, it may be better to leave entered data on the display until the user takes an explicit action to clear the display. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In a sequence of routine, repetitive data entry transactions, successful completion of one entry might result simply in regeneration of the initial (empty) data entry display, in order to speed the next entry in the sequence. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.5.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.0/3 Feedback During Data Entry3.0/14 Feedback for Control Entries4.2/1 Consistent Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>12 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/12 Feedback for Completion of Data Entry</span></text>
</content>
<name>1.0/12</name>
<script></script>
</card>
card_6976.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Require a user to take an explicit action in order to cancel a data entry; data cancellation should not be accomplished as a side effect of some other action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">If a requested sequence control action implies a more definite interruption, such as a LOG-OFF command, or a command to return to a menu display, then the user should be asked to confirm that action and alerted to the loss of any data entries that would result. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, casual interruptions of a data entry sequence, such as paging through forms, or detouring to HELP displays, should not have the effect of erasing partially completed data entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.3 Interrupt</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>11 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/11 Explicit CANCEL Action</span></text>
</content>
<name>1.0/11</name>
<script></script>
</card>
card_6695.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Label an ENTER key explicitly to indicate its function. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">For a novice computer user, the label should perhaps be even more explicit, such as ENTER DATA. Ideally, one consistent ENTER label would be adopted for all systems and so become familiar to all users. Some other label might serve as well, if it were used consistently. In some current systems the ENTER key is labeled GO or DO, implying a generalized command to the computer, "Go off and do it." </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, the ENTER key should not be labeled in terms of mechanism, such as CR or RETURN or XMIT. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Pew Rollins 1975 § 3.3.9</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/16 Compatibility with User Expectations4.0/10 Clear Control Labels</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>10 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/10 ENTER Key Labeling</span></text>
</content>
<name>1.0/10</name>
<script></script>
</card>
card_6590.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Always require a user to take an explicit ENTER action to initiate processing of entered data; do not initiate processing as a side effect of some other action. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Deferring processing until after an explicit ENTER action will permit a user to review data and correct errors before computer processing, particularly helpful when data entry is complex and/or difficult to reverse. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">In routine, repetitive data entry transactions, successful completion of one entry may automatically lead to initiation of the next, as in keying ZIP codes at an automated post office. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, returning to a menu of control options should not by itself result in computer processing of data just keyed onto a display. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>MIL-STD-1472C 1983 § 5.15.2.1.4</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/1 Combined Entry of Related Data1.4/2 Flexible Interrupt3.0/5 Control by Explicit User Action4.0/2 Explicit User Actions6.0/9 Control by Explicit User Action6.3/5 Explicit User Actions</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>9 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/9 Explicit ENTER Action</span></text>
</content>
<name>1.0/9</name>
<script></script>
</card>
card_6249.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Allow users to pace their data entry, rather than having the pace being controlled by computer processing or external events. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">The timing of user-paced data entry will fluctuate depending upon a user's momentary needs, attention span and time available. At maximum speed, user-paced performance is more accurate than that achieved by machine pacing. When user pacing does not seem feasible, as in some real-time process control applications, reconsider the general approach to task allocation and interface design. </span></text>
<text><span class="style10">Γêå Statement</span><span class="style1">In keyed data entry, always allow users to change previous entries if necessary (including displayed default values) by delete and insert actions; if data change is sometimes made by direct character substitution ("typeover"), then that option should also be consistently available. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Text editing on an electronic display can be handled with or without typeover; there seems to be no published research on the relative efficiency of user performance under these two conditions. Using typeover, there is some risk of user confusion in replacement of an old value with a new one, during the transitional period when the item being changed is seen as a composite beginning with the new value and ending with the old. Some designers do not permit overtyping for that reason. In some applications it may help the user to key a new entry directly above or below display of the prior entry it will replace, if that is done consistently. Here the user can compare values before confirming entry of the new data and deletion of the old. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Form filling may require typeover to replace displayed characters such as underscores that act as field delimiters. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/7 Consistent Method for Data Change</span></text>
</content>
<name>1.0/7</name>
<script></script>
</card>
card_5738.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Where data entry on an electronic display is permitted only in certain areas, as in form filling, provide clear visual definition of the entry fields. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">Display formats with field delimiters provide explicit user guidance as to the location and extent of data entry fields. Where delimiters extend throughout an entry field, as in underlining, then any keyed data entries should replace the delimiter characters on the display. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For general text entry of variable (unrestricted) length, no field delimiters are needed. In effect, keyed text entries can replace nothing (null characters). </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Data entry fields might be underlined, or perhaps highlighted by reverse video. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Brown etal 1983 § 2.2.1</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.4/10 Marking Field Boundaries</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>6 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/6 Defined Display Areas for Data Entry</span></text>
</content>
<name>1.0/6</name>
<script></script>
</card>
card_5400.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Design the data entry transactions and associated displays so that a user can stay with one method of entry, and not have to shift to another. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This, like other guidelines here, assumes a task-oriented user, busy or even overloaded, who needs efficiency of data entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">Minimize shifts from lightpen to keyboard entry and then back again. As a negative example, a user should not have to shift from one keyboard to another, or move from one work station to another, to accomplish different data entry tasks. </span></text>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/5 Single Method for Entering Data</span></text>
</content>
<name>1.0/5</name>
<script></script>
</card>
card_5236.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that the computer will acknowledge data entry actions rapidly, so that users are not slowed or paced by delays in computer response; for normal operation, delays in displayed feedback should not exceed 0.2 seconds. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">This recommendation is intended to ensure efficient operation in routine, repetitive data entry tasks. Longer delays may be tolerable in special circumstances, perhaps to reduce variability in computer response, or perhaps in cases where data entry comprises a relatively small portion of the user's task. Note that this guideline refers to acknowledgment, rather than final processing of entries which may be deferred pending an explicit ENTER action. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">A key press should be followed by seemingly immediate display of its associated symbol, or by some other appropriate display change. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § Table 2</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/18 Appropriate Computer Response Time3.0/19 Control Availability</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>4 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/4 Fast Response</span></text>
</content>
<name>1.0/4</name>
<script></script>
</card>
card_4972.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Provide displayed feedback for all user actions during data entry; display keyed entries stroke by stroke. </span><span class="style10">ΓêåΓêå Exception</span><span class="style1">For reasons of data protection, it may not be desirable to display passwords and other secure entries. </span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>Engel Granda 1975 § 6.3.7MIL-STD-1472C 1983 § 5.15.2.1.2 5.15.2.2.3</text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>3.0/14 Feedback for Control Entries4.2/1 Consistent Feedback</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>3 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/3 Feedback During Data Entry</span></text>
</content>
<name>1.0/3</name>
<script></script>
</card>
card_4703.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">When data entry is a significant part of a user's task, entered data should appear on the user's primary display. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">When the primary display is basically formatted for other purposes, such as a graphic display for process control, a separate window on the display may have to be reserved for data entry. </span><span class="style10">ΓêåΓêå Example</span><span class="style1">As a negative example, entry via typewriter is acceptable only if the typewriter itself, under computer control, is the primary display medium. </span></text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>2 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style20">1.0 General</span><span class="style21">1.0/2 Entry via Primary Display</span></text>
</content>
<name>1.0/2</name>
<script></script>
</card>
card_3891.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style10">Γêå Statement</span><span class="style1">Ensure that a user need enter any particular data only once, and that the computer can access those data if needed thereafter for the same task or for different tasks. </span><span class="style10">ΓêåΓêå Comment</span><span class="style1">In effect, this recommendation urges integrated and flexible software design so that different programs can access previously entered data as needed. Requiring re-entry of data would impose duplicative effort of users and increase the possibility of entry error. </span></text>
</content>
<content>
<layer>background</layer>
<id>9</id>
<text>1.8/9 User Review of Prior Entries1.8/1 Default Values</text>
</content>
<content>
<layer>background</layer>
<id>10</id>
<text>1 of 944</text>
</content>
<content>
<layer>background</layer>
<id>23</id>
<text><span class="style19"> DATA ENTRY</span><span class="style1"></span><span class="style20">1.0 General</span><span class="style21">1.0/1 Data Entered Only Once</span></text>
